Hey this is Isaac,

This week has been about closing loops. I'm releasing the DevRelifier (product for helping share and promote tech stuff), which means dealing with the unsexy parts of software development: tax setup and final testing.

It’s less about coding creative features and more about ensuring the business actually works without breaking the law or the user experience.

If you want to try the product, reply to this email for more info and free credits.

The Build: The Unsexy Last Mile

Shipping a SaaS isn't just git push and a prayer.

If you sell software, you may be subject to sales tax based on where your customers are located. In many jurisdictions, if you cross a threshold (often ~$100k revenue or 200 transactions), you legally have a "nexus" there and must file taxes. Tracking and managing the filing timing based on volume is not something I have the expertise to do or the desire to learn.

So here’s what I did:

1. Calculation & Collection: I configured Stripe to automatically calculate and collect the correct tax percentage at checkout based on the customer's location. It charges 0.5% per transaction, but I'm happy to pay that…for now.
2. Filing & Monitoring: I use a service called Numeral. They monitor my transaction volume via a stripe integration and alert me when I hit a nexus threshold in a specific state. Once I hit it, they handle the state filings. Stripe also has a service for this, but Numeral seemed much better.

It was great to glue Stripe and Numeral together and get to contacting potential customers.

The Learn: Ship Before You Are Ready

Another product I've been working on is called Plot Builders, designed to help new authors write novels as hobbyists. We had a vision, we built a slick linear process, and we thought it was really great.

We shipped it quickly to some free users, and we found we had the wrong idea about how users would use it.

The Assumption: We assumed authors would come with a title and a clear idea, moving linearly from Outline → Draft.

The Reality: Users struggled to name their projects. They felt restricted by the linear flow. It felt too high stakes to enter information. They wanted to jump around and explore.

The Pivot: We rebuilt the app.

• Brainstorming First: We added a brainstorming flow with some "cycling random questions" feature to help make the on-ramp easier.
• AI Titles: We made titles auto-generated to move naming to the end.
• Non-Linear View: We simplified the project into a single view where the outline slowly expands, rather than forcing users through more opinionated steps.

This is why early shipping matters. The original app had bugs and wasn’t fully tested. But if we had waited to perfect the code, we would have polished a product nobody wanted. Ship early to validate the workflow.

The Refactor: Sleeping Better with E2E Tests

I have unit and integration tests for DevRelifier, but nothing gives me confidence like End-to-End tests that simulate a user.

I created a suite using Playwright that simulates a full user journey: logging in via Clerk, creating a bundle, uploading files, generating a blog, and deleting the project.

The best part? Running them in "headed" mode with a slow-motion setting. A browser pops up and you actually watch the ghost user click through your app.

`pytest tests/test_e2e.py::test_complete_generation_journey --headed --slowmo=400`

A couple weeks ago I added a minimal example of the basic setup in the air web dev framework. Then I created a +clerk_test user (which Clerk recognizes to accept the hardcoded OTP 424242), handle the redirects, and verifies the UI elements exist.

These tests are too slow for the inner dev loop, but they are the ultimate final check. Watching the test suite verify the entire bundle creation flow is satisfying, and knowing I can deploy without manually clicking through every screen is fantastic.

Until next week,

Isaac

​
​