From Requirements to Production: How I Ship as a Solo Developer

Shipping alone is not heroic. It is a sequence of boring decisions made early enough that Friday night does not become incident theater.

I build client systems and in-house products with a small team at CSSolutions, and plenty of stretches where I am the person who gathered requirements, picked the stack, shipped the release, and answered the "payments look wrong" message. This is the Solo developer project workflow I actually use, from intake to maintenance, shaped by work like Trax, DealGPT, Zesty, Soma, and Mojo-360.

It is not the same as scoping an MVP thesis or using AI as a drafting partner. Those matter. This is the end-to-end delivery path: what to lock, what to build with, how to deploy, and what to stay paranoid about when money or inventory is involved.

Start with the job, not the feature board

Every project begins with the same intake questions, whether the client is a retailer or I am greenlighting an in-house product.

1. Who pays, and who uses it daily?
2. What painful job must work every week?
3. What systems already own truth (ERP, WhatsApp, spreadsheets, a legacy site)?
4. What is out of scope for v1 even if someone asked for it twice?
5. What failure would damage trust on day one?

On Trax, the trust failure was a gate pass that lied. On Zesty, it was a kitchen ticket that never arrived during dinner. On Mojo-360, it was a subscription that charged without unlocking content. Name that failure early. It becomes your quality bar.

What I capture in writing

I leave the first discovery call with a short note the client can correct. If they cannot edit it, they never agreed to it.

If those answers are fuzzy, I do not jump into design systems and screens and hope. I schedule another call. Ambiguity is cheaper before you invent tables.

Choose a stack you can operate alone

Portfolio variety is useful for clients. Night-time ops prefers boredom.

My go-to lanes:

How those defaults show up in real work

• Trax: Next.js admin, Node API, Expo mobile, Socket updates, role-specific dashboards. The stack was familiar. The hard part was shared language for transfers and gate passes.
• DealGPT: React + Vite front end, Supabase, AWS pieces, containerized deploy. AI features sit on top of boring auth and tenancy, not the other way around.
• Zesty / Soma: Multi-tenant SaaS habits, clear module boundaries, mobile access where the floor or field needs it.
• Mojo-360: Video and subscriptions force resumable uploads, webhook-safe billing, and a mobile offline story you can explain.

Technology is leverage only after the workflow is clear.

Requirements become a build plan

I translate discovery into slices that can ship independently:

1. Identity and tenants
2. Core workflow
3. Money or inventory side effects
4. Notifications and audit
5. Admin / support visibility
6. Hardening and go-live

Estimate in outcomes, not hours of "coding." "Store manager can create a transfer and security can clear a gate pass with limited connectivity" is a better ticket than "build inventory module."

A practical sequencing rule

I never start reporting dashboards before the mutation path works. I never start a second role's UI before the first role can finish the job. I never wire payments before the product state machine has names for trial, active, past due, and canceled.

If a stakeholder wants all four at once, I show the dependency order on one page. Most people accept it when they see what breaks otherwise.

Build with production habits from week one

Solo speed dies when staging and production behave like different products.

Non-negotiables early:

• Environment variables documented in one place
• Staging that uses the same auth and webhook patterns as production
• Error tracking before the first external user
• Migrations that can run forward without folklore
• Feature flags or simple config for risky releases

I keep UI component-driven and API contracts boring. Mobile and web should not invent parallel domain names for the same thing. That sounds pedantic until you debug "transfer" vs "shipment" vs "gate pass" at 11pm.

What I test while building, not after

Finance, billing, and inventory: stay paranoid

Anything that moves money or stock needs a different quality bar. Checkout UI is the easy part.

For restaurant and retail flows (Zesty, Trax), settlement and gate-pass accuracy beat fancy analytics. For subscription media (Mojo-360), trial, cancel, and resume paths need explicit tests. For deal and finance-adjacent tools (DealGPT, Soma), treat sensitive records like production money even when the invoice is "just software."

A money-path rehearsal I actually run

Before real users, I walk staging with a second brain (or a teammate) and try to break entitlement state:

1. Start a trial, expire it, confirm access dies.
2. Pay successfully, then replay the webhook.
3. Fail a payment mid-flow and recover.
4. Refund or void and confirm the product state matches finance reality.
5. Attempt a privileged action as a lower role.

Deploy like you will be paged

My production path is intentionally dull:

1. Main branch protected
2. CI runs lint/tests on pull requests
3. Staging deploy on merge or release candidate
4. Smoke the core loop manually: login, main job, one payment or inventory action
5. Production deploy with migrations first or in a controlled step
6. Watch error spike and webhook health for an hour

Hosts change. The ritual does not. Docker images, platform builds, or static frontends in front of an API: pick one pipeline and write the rollback in plain language.

Rollback is a product feature

If you cannot say how you undo the release in two sentences, you do not have a release plan. For database migrations, that means expand/contract steps when needed. For feature risk, that means a flag. For content or config, that means a previous known-good artifact.

Maintenance is part of the product

Launch is the start of the cheaper, quieter work: keeping trust.

Weekly solo ops rhythm:

• Scan error tracker and slow queries
• Confirm backups and certificate expiry
• Review failed jobs / webhooks
• Patch dependencies on a cadence, not a panic
• Touch one piece of tech debt that protects money, auth, or data integrity

Monthly, I also review:

• Unused admin powers and stale invites
• Storage growth and log retention
• Provider dashboard anomalies (auth, payments, email)
• The top five support themes, then decide if the product or the docs need to change

Clients and co-founders hear "maintenance" as optional. It is not. The alternative is rebuilding trust after a silent billing bug.

Client and stakeholder communication that saves weeks

Solo delivery fails socially more often than technically.

What works:

• A shared definition of done for the milestone, not a vague "almost ready"
• Staging demos with real roles, not only founder admin accounts
• Change requests written as scope swaps, not free additions
• A single channel for launch decisions

What burns calendar:

• Redesigning the homepage while the core loop is unfinished
• Parallel "quick" mobile apps before the API contract is stable
• Launch dates announced before webhook and backup proof exist

What teams should stay mindful of

Whether you are solo or three people:

• Do not start UI before the workflow sentence is boringly clear
• Do not add a second mobile stack because someone saw a demo
• Do not treat staging as optional if payments or inventory exist
• Do not skip audit logs on money and stock mutations
• Do not confuse shipping features with reducing operational risk
• Do not let AI-generated scope override a buyer you have not interviewed

The goal is a product a stranger can use, you can explain, and you can keep alive without heroics.

A compact end-to-end map

If you want the product-strategy companion to this delivery path, read SaaS app development from MVP to production. If AI is in your loop, keep the judgment rules from using AI without the generic output.

The stack will change. The sequence does not: clear job, boring foundations, paranoid money paths, deploy ritual, maintenance you actually do.