My second SaaS started from the code of the first: what I could reuse and what I had to rewrite

Where the idea came from

When I repositioned Estoque Simples as a stockroom tool, I created a page for each type of operation: clinics, condos, schools, construction sites and auto repair shops.

The auto shop page started a different kind of conversation. Nobody at a repair shop just wanted to know how many brake pads were on the shelf. They wanted to know which car the part went into, under which work order, and whether the customer had already approved the quote.

For a repair shop, inventory is a consequence. The center of the day is the work order. That is how Oficina Simples was born: a management system for auto repair shops that started, quite literally, as a copy of the Estoque Simples codebase.

What came for free

A large part of any SaaS has nothing to do with the problem it solves. All of this came for free:

• Multi-tenancy: each shop is a company, and every business model is isolated by a global scope. Nobody sees another company's data, not even by typing the URL.
• Full authentication: email verification, 2FA, password change with confirmation and protected sessions.
• Plans and recurring billing: subscriptions, plan changes, the payment gateway webhook and the free trial flow.
• Privacy compliance (LGPD): versioned legal documents, recorded consent, data export and a channel for data subject requests.
• SEO and acquisition: a compiled landing page, audience pages, sitemap, share image and a canonical domain.
• Business model: the same design I had already validated. A 14-day trial with everything, a free plan that works as a floor, and a single Pro plan.

That last point deserves a highlight. When the trial ends or a payment fails, the shop drops to the free plan. It is never locked out. That rule took weeks to design in the first product and came in a single line in the second.

What I had to rewrite

The domain. And it was much bigger than I expected.

A work order is a process, not a record. A product in inventory has a quantity and a history. A work order has states: draft, quote sent, approved, in progress, ready, delivered. Each transition triggers something different: deducting parts, charging, notifying the customer, calculating commission.

The end customer entered the system. In Estoque Simples, only the internal team used the panel. At a repair shop, the car owner gets the quote through a link, approves it on their phone and follows the vehicle history in a portal. These are public pages, accessed by token, rate limited and kept out of Google's index. An attack surface the first product simply did not have.

Tax invoicing became mandatory. An internal stockroom does not issue invoices. A repair shop issues invoices for parts and for services, each with its own rules. That turned into an entire module, and a post of its own.

The cost nobody shows: two codebases

Forking was the right call to start fast. But it has a cost that shows up in the first week: every fix to the shared base has to be made twice.

A concrete example: I implemented the redirect to the canonical domain in Estoque Simples. A few days later, the same middleware, with the same test, had to go into Oficina Simples. It is not hard, but it is easy to forget.

I considered extracting the base into a shared package and decided not to do it yet. The reason is simple: with two products, I still do not know what is truly common and what only looks common. Abstracting too early freezes decisions that are still going to change.

The rule I adopted:

• Two products: fork, with a living list of fixes that need to be replicated.
• Third product: then extract what all three use in the same way.

What I would do the same way again

1. Copy the infrastructure, not the domain. Login, billing and privacy compliance look the same in any B2B SaaS. The way the customer works never does.
2. Keep the tests in the fork. The first product's test suite caught several breakages when I started changing models in the second.
3. Reuse the business model, but validate it again. The price that makes sense for a stockroom is not automatically the price for a repair shop.

The second product did not ship in half the time of the first. But it shipped without redoing any of the parts I already knew how to build, and that left all the energy for the part that matters: understanding how a repair shop works.