SaaS Product Development, From First Version to Paying Users

The screens are the easy part. What decides whether you can sell it is sign-up, taking payments, keeping each customer’s data properly separate, who is allowed to do what, and an admin view you can use at three in the morning. We agree a first shippable version, price that, and decide the next stage once real users are on it.

That is the normal route, and a product is never one quote. We scope a first version that is small enough to ship and complete enough to charge for, because an MVP that cannot take money does not tell you anything. What you learn from the first paying users then sets the second stage.

There is no single figure, because a five-page brochure site and a site with a cost estimator, logins and payments are different pieces of work. What drives the number is how many distinct screens there are, how many kinds of user it serves, whether it needs to connect to anything you already run, and how much of the content and photography exists already. We quote once, in writing, after a short call, and that figure does not move unless you change the scope.

A straightforward business site is usually a few weeks; something with accounts, payments or custom logic runs longer. The honest answer is that the build is rarely what sets the date. Waiting on content, photography and approvals is, which is why the scope is signed off before anyone opens an editor and why you get a working build to click every week.

Yes, both. On final payment the source code is yours, every account is created in your name, and you get a handover pack: architecture diagram, functional flow, API documentation, component list and security notes. Any developer can pick the project up later without starting over. You are not locked to us by anything except whether you want to keep working with us.

Senior engineers, not juniors learning on your project. Our engineers came from enterprise product teams inside large multinational companies, on software used by over a million people worldwide, and that is the standard your project is held to. The person you brief is the person who writes the code, with no account manager relaying messages in between. You are always told who is working on your project.

Yes. Most of our work is with Chennai and Tamil Nadu businesses, particularly construction, interiors and retail, and we also work remotely with clients elsewhere in India and in the US and UK, in English. The weekly check-in and the clickable build matter more than being in the same city, and they work the same either way.

We ship it, hand over the documentation, and stay reachable. There is no compulsory monthly retainer and no licence that expires. If you want ongoing changes we agree that separately; if you want to take it to another developer, the handover pack exists so you can.