The problem
You are probably here because
If software is the product rather than the back office, the requirements change: sign-ups, plans, billing, tenant separation, and a support story. We build for that from the first commit.
- You built something internally and customers keep asking to buy it.
- You need a first version in front of paying users to know if this is real.
- You have a waiting list and nothing to put them on.
- An investor conversation is coming and a slide deck is not enough.
Included
What you get
Written down before anything is built, so you can price the conversation and hold us to it.
- Customer separation done right
- Each customer sees only their own data, enforced in the database rather than the interface. Getting this wrong once ends a young product.
- Sign-up, plans and billing
- Self-service sign-up, plan changes, trials, failed-payment recovery, invoices and tax handling, through Stripe.
- Onboarding that gets people to the point
- The first ten minutes decide whether someone stays. We build for that moment specifically.
- Numbers you can run the business on
- Sign-ups, activation, active accounts, churn. On a screen, not reconstructed from Stripe exports.
- Built to hand over
- Standard tools, ordinary patterns, real documentation. Your future in-house team should be able to read it without us.
Process
How a project runs
In this order, with something you can look at early rather than a reveal at the end.
- 01
Cut the scope hard
The fastest way to kill a first version is to build all of it. We find the smallest thing someone would pay for.
- 02
Build the spine first
Accounts, permissions and billing. Boring, and the part that is painful to retrofit.
- 03
Get real users on it
A private group of real customers before public launch. What they do with it decides what gets built next.
- 04
Launch, measure, extend
Public launch with analytics from the first day, then a build queue driven by usage rather than opinion.
Tools
What we build with
- Next.js
- PostgreSQL
- Stripe
- Vercel
Ordinary, well-documented tools that other developers already know. Nothing proprietary that only we can maintain.
Industries
Where this comes up
The same problem looks different depending on the trade. These pages go into what it looks like in yours.
- SchoolsAdmissions, attendance, parent portals and fees.SaaS Platforms for schools
- ClinicsAppointments, reminders, intake and records.SaaS Platforms for clinics
- HotelsBookings, front desk, guest messaging and housekeeping.SaaS Platforms for hotels
- EngineeringQuotes, job tracking, site reports and scheduling.SaaS Platforms for engineering
Questions people ask
How small should the first version be?
Smaller than feels comfortable. One problem, solved properly, for one type of customer. Everything else is a guess until people are using it.
Can we start with the internal tool we already have?
Often yes, and it is a good sign that you have one. It usually needs accounts, billing and customer separation added rather than a rewrite.
What about hosting costs as we grow?
We design so cost scales with customers rather than jumping. Early stage this is typically tens of dollars a month, not thousands.
Will we be locked into you?
No. You own the code and the accounts, we use standard technology rather than anything proprietary, and we write the documentation an incoming team would need.