
SaaS development
Launch software people sign up for, start using quickly and keep paying for.
We design and build your subscription software end to end - signup, onboarding, the core features, user roles and billing - built to be maintained, and owned outright by you.
Available on its own, or as part of The Product Build.
In practice
What this actually is
This is building software you sell by subscription rather than software you use yourself. It is a product, a pricing model and an ongoing relationship with the people paying monthly, and all three have to be designed, not just the screens.
What we do
- Product strategy
- What the first version has to prove, who it is for, and what can wait.
- UX and interface design
- The screens, and the first ten minutes that decide whether somebody stays.
- Development
- The build, structured so a second developer can read it in an afternoon.
- Subscription and billing
- Plans, trials, upgrades, failed payments and the awkward cases in between.
- User and team management
- Accounts, roles, invitations and permissions.
- Product dashboards
- What your customers see, and what you need to see about them.
- Analytics and retention
- The handful of numbers that tell you whether people are staying.
- Ongoing development
- The roadmap after launch, informed by what users actually do.

A product with room to grow
Built with the next version in mind.
A stronger foundation for a software business that has to keep moving: a considered first version, clearer priorities, and an architecture that does not treat launch day as the finish line.
Start the conversationYou are not selling software, you are selling the second month
Every subscription business has the same shape and the same trap. The sale feels like the finish line, and it is not even the start of the thing that matters. What matters is whether the customer reaches something genuinely useful quickly enough to justify the next payment - and industry-wide, most of them never do.
The numbers are consistent and they are uncomfortable. Across benchmarked business software, only around a third of new signups ever reach the core thing the product was built to deliver. The rest sign up, look around, and quietly stop - and the overwhelming majority of people who fail to hit a real value milestone inside the first fortnight are gone. A meaningful slice of a whole year of churn is created in the first ninety days, before anybody has properly used the thing.
The other half nobody budgets for is the unglamorous half. Subscriptions fail on expired cards as well as on disappointment, and involuntary churn is a quarter of the problem in most benchmarks - a genuinely solvable quarter, lost by products that treated billing as a switch to flip at the end.
37%
The average share of new signups who ever reach the core value of the product they signed up for. Two thirds never see what they paid for.
98%
Of users who do not hit a real value milestone within a fortnight are gone. The window is far shorter than most roadmaps assume.
1 in 4
Of all churn is involuntary - failed cards and expired payment details. Nobody chose to leave; the billing simply was not built to hold them.
The discipline
Four layers, and only two of them are features
A subscription product is built in this order. Founders start at layer three because it is the fun one, then spend a year discovering that layers one, two and four were what the business was actually made of.
The wedge
One job, done unarguably well
- The single problem it solves
- Who has it badly enough to pay
- What it replaces today
- What it deliberately does not do
This holds it up
The first week
A new user reaches the point
- Signup with the least possible in the way
- The first useful moment, defined
- Setup that does not need a call
- Something to come back to on day two
They see this
The product
It earns the next month
- The work people came to do
- Accounts, teams and permissions
- Data they can get back out
- It stays quick as they grow
They see this
The money
Revenue actually collects
- Plans, trials and upgrades
- Failed payments retried
- Cancellation that tells you why
- Revenue you can read
This holds it up
Layers one and four are where subscription businesses are won and lost, and both are invisible in a demo. That is exactly why they get postponed - and why postponing them is the most reliable way to build a product with an impressive feature list and a leaking bucket underneath it.
Measurement
How you will know it is working
SaaS development South Africa is measured on whether people stay. These are the numbers that say so early enough to act on.
What we report on
- Activation rate - the share of signups reaching the first useful moment, and how long it takes
- Retention at day seven, day thirty and day ninety
- Monthly churn, split into voluntary and involuntary, because they have different fixes
- Revenue recovered by dunning, which is usually the cheapest revenue in the business
- Where new users stop, named by step rather than guessed at
Before you ask
The questions that come up first
What should version one include?
Less than you think, and it is the single biggest decision in SaaS development South Africa founders get wrong. One job, done unarguably well for a specific person, and nothing else. A narrow version one ships, gets used, and tells you what to build next from evidence. A broad one absorbs the runway and reaches the market late with a feature list nobody asked for.
Do I need to have customers before you build?
You need evidence that somebody wants it, which is not the same as having built it. If you have not tested that yet, start with a prototype - it is faster, far cheaper, and it is the same team. Building first and validating afterwards is the single most common way a product budget disappears.
What does it run on, and who pays for that?
Hosting, database and services sit in your own accounts and you pay those providers directly, the same way you own your own ad account. We set them up, document them and tell you what they will cost at your expected load before you commit. You are never billed for infrastructure through us.
Can you run it after launch?
Yes, and it is quoted separately so you can see what it is. Software with real customers on it needs somebody accountable for uptime, updates and security. If you would rather your own team took it, we hand over documented code and accounts and help them in.