First versions
The smallest product a customer will pay for: one core workflow done properly, with sign-in, billing and the admin tools to support it.
- The core workflow end to end
- Sign-in and team accounts
- Billing on one or two plans
Build the software your customers pay for
Accounts, dashboards, billing and roles, plus the admin tools your team runs the product with.
At a glance
- An architecture and data model document, agreed before the build
- A working web application on your own domain
- Sign-in, team accounts and roles
- Billing connected to Stripe or Razorpay in your own account
Timeline3 to 5 months for a first version that customers can sign in to and pay for
At handoverYou own the code, accounts and documents
Is this where you are?
Customers are waiting for a product
You have pilot customers or signed interest, and need a working first version they can sign in to and pay for.
Your service runs on spreadsheets
You deliver a service by hand today and want to turn the repeatable part into software customers use for themselves.
Your prototype has hit its limits
A no-code tool or quick freelance build got you started, but sign-in, billing or keeping each customer's data apart is now breaking.
You bill customers in two markets
Customers in India pay by UPI or card and expect GST invoices, while UAE customers pay by card and expect VAT invoices.
What we build
Accounts, teams and roles
Each customer gets its own workspace with many users, and each user sees only what their role allows them to see and change.
- Organisations with many users
- Roles and permissions
- Team invites and Google sign-in
Billing and subscriptions
Plans, trials, upgrades and invoices, set up through Stripe or Razorpay so card details never pass through your own servers.
- Plans, trials and upgrades
- Subscriptions through Stripe or Razorpay
- Invoices with the right tax details
Dashboards and reports
The screens your customers check every day, showing their own numbers clearly, with exports they can send on to their managers.
- Customer dashboards
- CSV and PDF exports
- Scheduled email reports
Admin tools for your team
Internal screens to look up a customer, see what they pay for, change their plan and help them without touching the database.
- Customer lookup and support view
- Plan and feature switches per customer
- Usage and revenue reports
Integrations and APIs
Connections that let your product send and receive data from the tools your customers already use, plus an API for their developers.
- A public API with access keys
- Webhooks for key events
- Connections to tools such as HubSpot, Zoho or Google Workspace
Rebuilds from no-code or prototypes
Moving a product that has outgrown its first build onto a proper data model, without losing customer data or forcing everyone to switch on one day.
- A review of the current data and workflows
- Data moved from the old tool
- A staged switch-over for existing customers
Documentation and handover
Written records of how the system works and how to run it, so your own engineers or a future team can take it over.
- Architecture and data model documents
- A runbook for releases and backups
- Handover sessions with your engineers
How a project runs
- Weeks 1 to 2
Model the data
We map your customers, users, plans and core records, and agree the architecture in writing, because changing it later costs the most.
- Weeks 2 to 4
Design the screens
We design the main customer screens and admin tools as a clickable prototype and test it with one or two of your pilot customers.
- Weeks 4 to 16
Build in slices
We build one complete feature at a time, from database to screen, and you use the working product at every Friday demo.
- Weeks 14 to 19
Open to pilot customers
A small group of customers starts using and paying for the product while we fix what they find and watch the admin reports.
- Final 2 weeks
Hand over the system
We finish the documentation, move every account into your name and walk your team or engineers through running the product.
What you get
- An architecture and data model document, agreed before the build
- A working web application on your own domain
- Sign-in, team accounts and roles
- Billing connected to Stripe or Razorpay in your own account
- Admin tools and reports for your team
- Source code in a repository you own
- Hosting, database and monitoring set up in your own cloud accounts
- A runbook for releases, backups and common support tasks
- Technical documentation and recorded handover sessions
Tools we choose from
We choose the stack per project, favouring tools with plenty of developers available so you can hire for them later.
Application
- Next.js
- React
- Node.js
Data and sign-in
- PostgreSQL
- Supabase
- Google sign-in
Billing
- Stripe Billing
- Razorpay Subscriptions for UPI and cards in India
Hosting and monitoring
- Vercel
- AWS
- Sentry for error tracking
Ways to work together
Architecture review before you build
A short fixed project to agree the data model, stack and first-version scope, which you can take to us or any other team.
Fixed-scope first version
A written scope with price and timeline agreed before we start, working software at every Friday demo and a full handover at the end.
Ongoing development, if you want it
After launch we can keep building in monthly cycles until you hire your own engineers, then hand over to them.
Questions about web apps and SaaS
Who owns the code and the data?
You do. The code sits in a repository in your name, and hosting, database, billing and monitoring run in accounts you own. Your customers' data never lives in an account controlled by us. At handover we remove our access unless you ask us to keep it for ongoing work, and you can remove it yourself at any time.
How do you keep one customer's data away from another's?
We decide this at the start, in the data model. Every record belongs to a customer workspace, and access rules in the database check that a user can only read and change their own workspace's records. We test these rules on every release, because a mistake here affects every customer at once.
Stripe or Razorpay?
It depends on where your customers are and how they pay. Razorpay handles UPI and Indian cards well and supports subscriptions. Stripe is common for international card payments and is available in the UAE. Some products use both, routing customers by country. We recommend one in the scope, and the billing account is always set up in your company's name.
Can our own engineers take over later?
Yes, and we plan for it from the start. We use widely known tools, keep the code readable, write down how the system is built and run, and record handover sessions. If you hire engineers during the build, they can join the Friday demos and start working in the code before we leave.
What about data protection rules in India and the UAE?
Both India and the UAE have data protection laws that cover how customer data is collected, stored and shared. We build in the basics, such as consent records, access controls, data export and deletion on request, and we tell you where your data is hosted. For your specific obligations, take advice from a lawyer who practises in each market.
How much does a SaaS first version cost?
We do not publish prices, because the effort depends on the workflows, roles and integrations involved. After a free 30-minute call we send a written scope with a fixed price and timeline. Hosting, billing fees and other third-party services are paid by you directly to each provider, so you can see those costs for yourself.
Often paired with
Tell us what you are trying to build.
A thirty-minute call, no charge. If we are not the right team for it, we will tell you and point you to someone who is.