Skip to content
Back to Blog
shippingsaasprocess

How I shipped a SaaS in 6 months solo

Moulavi went from a messy agency workflow to a production visa platform in six months, with one builder. The method was constraints, not heroics.

3 min read

Moulavi shipped in six months. One builder. A B2B Umrah visa platform for travel agencies that had been running applications through WhatsApp and spreadsheets.

That sentence is easy to misread as a grind story. It was not. Six months is what you get when you refuse to build a platform and instead build a path.

Start with the illegal state

Agencies were losing time in the gaps: a document that never arrived, a status that meant different things to different people, an application that looked complete and was not. The product was not "a portal." The product was a workflow where an invalid application cannot enter production.

I designed the system as a state machine before I designed the screens. Every status had a name. Every transition had a rule. If a path was not legal, it did not exist in the API. The UI could not offer it.

That decision deleted months of work. No generic admin. No "just in case" modules. No settings page that reopened the chaos we were trying to close.

Solo is an architecture choice

Solo does not mean I typed every line by myself. It means there was one owner of the outcome. Architecture, frontend, backend, deployment, and the conversations with the people who would use it.

There is no translation layer in that setup. If a customer says "this status is lying," the person who hears it is the person who can change the transition table the same day.

I used Claude Code as the execution layer — scaffolding, refactors, debugging — so I could stay on the decision layer. That is how one person covers a surface area that used to require a small team, without pretending the team still exists.

What six months actually contained

The calendar was not a montage. It was a sequence of constraints:

  • Model the real agency workflow, including the ugly branches.
  • Encode it so illegal moves fail closed.
  • Put the UI on top of legal moves only.
  • Ship to production with a stack I could operate: TypeScript, Next.js, Express, Prisma, PostgreSQL.
  • Process real bookings. About 15–20 visa applications went through the system. Enough to prove the machine, not enough to confuse activity with scale.

Then regulatory changes on the client side paused operations. That is not a product failure. It is a constraint outside the codebase. The software did its job: it shipped, it enforced the path, and it stopped when the business context changed.

What I would repeat

I would repeat the state machine. I would repeat the single owner. I would repeat shipping before the feature list felt complete.

I would not repeat building anything that does not remove a failure mode. Six months is long enough to create a graveyard of tasteful screens. It is also long enough to make one workflow honest.

If you are shipping solo, you do not need more hours. You need fewer optional states.

The rest is execution.