An internal tool others want
A business builds a scheduling tool for its own staff, and partners keep asking to use it. Turning it into a product means separate accounts, billing and a proper sign-up, without breaking what already works.
SaaS products
Turn an idea into a product other businesses will pay for
Maybe you built a tool for your own business and other people keep asking for it. Maybe you've spotted a problem a whole industry has learned to put up with. Either way, the hard part isn't the idea. It's a first version small enough to launch and solid enough to grow.
We build and run software products of our own, so we know what it takes to get from a first release to paying customers, and what it takes to keep them.
- Agile, two-week cycles
- A demo of working software every cycle
- One team from build to support
Sound familiar?
The problems we usually hear first
If one of these describes your week, you're in the right place. Good projects often start with exactly this kind of frustration.
- 01
The idea keeps growing
Every conversation adds another feature, and the launch date keeps moving.
- 02
A prototype that can't grow
A quick first version works for one customer, then starts to struggle with the tenth.
- 03
Billing is an afterthought
Subscriptions, invoices and failed payments get handled by hand, and money quietly slips through.
- 04
Nobody to run it
The product launches, and then nobody is watching the servers, the support inbox or the updates.
What we cover
Everything a product needs to go from a good idea to something customers sign up for, pay for and keep using.
- 01
Shaping the first version
We help you decide what the first release must do and, just as important, what can wait. A smaller launch gets real feedback sooner.
- 02
Accounts for many organisations
Each customer gets its own workspace, with its own users, roles and permissions, and data kept separate from everyone else's.
- 03
Subscriptions and billing
Plans, trials, invoices and payment collection built in, so customers can sign up and pay without anyone on your side lifting a finger.
- 04
Admin tools and analytics
A back office for your team: who your customers are, how they use the product and where they get stuck.
- 05
Customer support features
In-app help, contact forms and the tools your team needs to answer questions quickly.
- 06
Hosting and updates after launch
We keep the product online, monitored and up to date, so you can spend your time on customers.
What you get
- A product customers can sign up for and pay for
- A separate, secure workspace for each customer
- An admin area for your team
- Usage figures that show what customers rely on
- Hosting, monitoring and updates after launch
Small first, then grow
We'd rather put a small product in front of real customers early than spend a year building in private. What they do with it tells us what to build next.
How we'll work together
Four steps from the first conversation to something your team uses every day, with the building done in two-week sprints. New to agile? Here's how it works.
Step 1 of 4
Shape the idea
We talk with you, and ideally with a few future customers, to pin down the problem and the smallest product that solves it.
- The problem, in your customers' words
- Who pays, and why
- The smallest useful first version
For example
A few situations where this kind of work makes a real difference.
An industry with no good software
Clinics in one specialty make do with general tools that don't fit how they work. A focused product built around their day is easier to sell than one that tries to suit everybody.
A founder with early interest
A founder has customers ready to pay but no technical team. A small first release gets those customers using it, and their feedback decides what gets built next.
Questions people ask
Something else on your mind? Ask us directly. There's no such thing as a silly question before a project.
Do I need a technical co-founder?
No. Plenty of good products start with someone who knows an industry well. You bring the problem and the customers; we bring the product and engineering experience.
How do you decide what goes into each release?
Together, at the start of every cycle. We look at what users did with the last release, what you're hearing from customers and what's holding back sales, then pick the work that matters most.
How much should the first version do?
Less than you think. We'd rather launch something small that a few customers use every day than something large that nobody has tried yet.
Can you help after launch?
Yes. Most products need steady work after launch: fixes, new features and the day-to-day running. We can stay on and do that with you.
Often paired with
Got a product idea worth testing?
Tell us who it's for and what it solves. We'll help you work out the smallest version worth building.