Online Products
From a first version to something a real business can run on.
What usually goes wrong
Getting a first version working is the easy half. What breaks a young product is everything the demo never needed. A second customer whose information must never be visible to the first. A failed card payment that quietly leaves an account switched on. A task that fails at three in the morning and tells nobody. A support question your team cannot answer because there is no screen that shows them the answer. Nobody asks for any of this, and it decides whether the product survives its first hundred customers.
What you end up with
- Each customer's information kept properly separate from every other customer's
- Payments and access that stay in step, including when a card fails or someone cancels
- Automatic work that tells someone when it fails, instead of failing quietly
- A screen your own team can use to answer customer questions, without asking a developer
Inside products work
First working version
The smallest version that answers the real question, built so version two is not a fresh start. Where we take a shortcut, we tell you it is a shortcut and what it will cost to undo.
Accounts and permissions
Signing in, teams, and who is allowed to see what. Built to hold up when your first large customer asks for their own rules, rather than being bolted on later.
Payments and subscriptions
Free trials, upgrades, downgrades, failed cards, refunds and cancellations. The unglamorous cases are the ones that lose money quietly, so they get the most attention.
Work that runs on its own
Scheduled reports, reminders, imports and anything that talks to another company's system. Set up so that when something fails, a person is told and it can be run again safely.
Knowing what is happening
Alerts when something breaks, and a small set of numbers worth watching. Set up to reach a person, not to sit on a screen nobody opens.
Handling growth
Finding the specific thing that is actually slow and fixing it, rather than paying for a bigger server and hoping the problem goes away.
What you get
- A product a team other than ours can run and keep building on
- Written instructions for the problems that are likely, not the ones that are interesting
- An admin screen for the questions your support team will really get
- Alerts that have been tested, not just switched on
- A written record of the decisions that would be expensive to reverse, and why we made them
What is not included
Saying this plainly saves everyone a call.
- Market research, pricing strategy or launch marketing
- Investor material
- Round the clock emergency cover, unless it is agreed separately
- Anything that needs a licence or certification we do not hold
How this runs
- 01
Understand the problem
What the product must do, for whom, and what has to be true for it to be worth building. We push back here if the plan is bigger than the question it answers.
- 02
Agree the shape
How the product will be put together and which decisions would be expensive to change later. Those get written down with the reasoning, so nobody has to guess in a year.
- 03
Build the foundation first
Accounts, payments, permissions and publishing before features. Adding any of them to a working product later costs several times more than starting with them.
- 04
Build features weekly
A working version every week on a private link, planned together and adjusted as you learn from real customers.
- 05
Keep it running
Alerts, written instructions, and either a handover to your team or ongoing support from us. Both are fine, and we tell you which one we think suits you.
How this is usually arranged
We do not publish rates, because a number without a clear scope would mislead you. You get a real, fixed figure in writing after one conversation.
Dedicated team
One or more people working only on your product for an agreed period, planning with you week by week. In practice it is your software team, without the hiring.
Best for
Ongoing product work where the plan will change as you learn from customers.
Monthly support
A set amount of our time each month for looking after your software, making small changes and improving things gradually. It rolls on monthly, can be stopped with thirty days' notice, and always ends with a handover document.
Best for
Software that is live and needs to stay safe, up to date and working.
Fixed price project
A defined result, a fixed price and a delivery date, all agreed before work starts. If you want something added later, it is priced separately rather than absorbed quietly or argued about at the end.
Best for
A well understood piece of work: a website, an app, a check of existing software.
What people ask about this
You do, once it is paid for, including everything produced along the way. It lives in your accounts from the first day, not ours. Hosting, your web address, app store listings and any other service are all set up in your name. Nothing about leaving us is made difficult on purpose.
A website or a focused web application is usually six to twelve weeks. A first release of an online product is three to six months. A mobile app is two to four months to the first store release. Checking existing software takes three to five days. Those are honest starting ranges. You get a real date in the written plan once we understand the job, and we would rather quote longer and be right.
Yes, and it usually goes well. We work in small pieces specifically so that someone else can check them. We agree how we will work together at the start, and we are happy for your team to own parts of the work while we own others, as long as the line between them is written down.
Three ways. A fixed price project for a clearly defined piece of work. A monthly arrangement for software that is live and needs looking after. Or a dedicated team, where people work only on your product for an agreed period. Every written plan names one of the three, so there is never any confusion about what you are buying.
You might also need
- 01Websites and Web AppsCompany websites, online shops, customer portals and internal tools, built so they stay fast and stay easy to change.
- 02Rescue and SupportFor software that already exists and has become risky to run. We check it, tell you plainly what is wrong, fix what matters, and keep it working.
Talk to us about this
Thirty minutes, nothing to prepare. We will tell you honestly whether we are the right studio for it.