Building a Product or Company From Scratch
Including the parts founders discover late.
In plain English
Taking an idea and turning it into a real product people can sign up for and pay for, including the unglamorous parts that decide whether it survives its first hundred customers.
The technical version: Building a product from scratch is mostly not the feature work. It is auth, billing, email deliverability, permissions, compliance, observability and cost, and those are what founders discover late, usually at the worst moment. I have taken products from nothing to shipped, sold two of them, and scaled one platform from zero to $50M in revenue, so the plan accounts for those from the start rather than treating them as later problems.
What you could actually do with this
The thing you have been describing to people becomes something they can actually use.
You stop selling a description and start selling a product, which is a completely different conversation.
Customers pay you through the product instead of you chasing invoices by hand.
Revenue arrives without anyone touching it, and you learn something is wrong from a dashboard rather than a bank statement.
Your emails reach inboxes rather than spam folders, and people can reset their own passwords.
Both sound trivial until they break, at which point they are the only thing anyone talks about.
You can add a customer without adding a person.
That is the whole difference between a product and an agency, and it is settled by architecture decisions made in the first month.
What it is worth
The cost of building is easy to see and easy to quote. The cost of building it twice, because the first version could not take payments, could not control who is allowed to see what, or could not pass a customer's security review, is the one that actually kills companies. That is the cost this buys down.
What I actually deliver
The technical detail, for whoever on your side has to check it.
- An architecture sized for the next 18 months, not for a hypothetical million users
- The build: the actual product, shipped, not a prototype handed over
- The unglamorous foundations done properly: authentication, permissions, billing, transactional email that arrives, backups that have been restored at least once
- A deployment path a small team can operate without a dedicated ops hire
- Cost modelled before you are surprised by it
- Compliance designed in when the market needs it, rather than retrofitted under deadline
How it works
- 01
Cut the scope to what proves the thing
What is the smallest product that tells you whether this works? Almost every first plan is two or three times bigger than that.
- 02
Choose boring infrastructure
Managed, well-documented, unremarkable technology. Novelty in the foundation is a tax you pay every week for years.
- 03
Build the foundations first
Auth, permissions and billing before features. Retrofitting a permissions model into a shipped product is one of the most expensive things in software.
- 04
Ship to real users early
Behind flags, with instrumentation. Real usage reorders the roadmap within days and is the only honest source of priority.
- 05
Hand over deliberately
Documentation, the first engineers hired and onboarded, and me stepping back on purpose rather than becoming a permanent dependency.
When this is the wrong call
If you have not spoken to people who would pay, the first spend should be on finding out, not on building. If the product only works with a large existing audience you do not have, the plan is a distribution plan, not an engineering one. And if you want a fixed price for an undefined product, any honest answer is a wide range: pay for a scoping engagement first and get a real number, or accept that a fixed bid on vague scope is padded and you are paying for the seller risk.
Where I have done this
Two exits
An ATS and HR onboarding SaaS built and sold with $400K ARR and 40+ clients, and a staffing platform scaled from zero to $50M revenue and a multi-million dollar exit serving 500+ clients.
Further reading
- Scaling from Zero to $50M: The Infrastructure Decisions That Mattered A case-study reflection on the architecture, hiring, and cost decisions that actually mattered scaling a startup from zero to $50M - and the ones that didn't.
- SmileShape: SOC 2, HIPAA & an 8-Figure Valuation in Under a Year As CTO and equity owner of SmileShape.ai, I took a health-tech AI company from day one to SOC 2 and HIPAA compliant, production-ready, and an 8-figure valuation in less than a year.
- SOC 2 for Seed-Stage Startups: What It Actually Takes A founder's guide to SOC 2 for seed-stage startups: what it is, the 5 Trust Services Criteria, the real process and timeline, and how to avoid over-scoping.
- How I Cut AWS Costs 70% for a DoD Contractor A real case study: the architecture fixes, right-sizing, and governance changes that took a defense contractor's AWS bill down 70% - without a migration or a re-platform.
Questions
Do you work with our engineers or instead of them? +
Either. With a team I embed and build alongside them, which also raises the standard of what ships after I leave. Without one I build it and then help you hire the people who will own it.
What stack will you use? +
Whatever your team can maintain, biased toward boring and managed: TypeScript and Python, Postgres, a managed platform rather than self-run Kubernetes. If you already have a stack and a team that knows it, that is usually the right answer even when it is not my favourite.
Can you get us to SOC 2 or HIPAA at the same time? +
Yes, and doing it while building is dramatically cheaper than retrofitting. I have taken a company to SOC 2 and HIPAA compliant while the product was still being built, which is the only time those decisions are inexpensive.
What happens when you leave? +
That is planned from the start: documentation, handover, and hiring the people who take it on. A fractional CTO who becomes permanently necessary has failed at the job.