SaaS products customers can sign up for, pay for and rely on
We build SaaS products that customers sign up for, pay for and rely on, with accounts, roles and permissions, billing, integrations, and the operations behind them. We run three SaaS products of our own, PostDeploy, KeySend and CrabGate, so we build yours knowing what running one takes. We test and review changes before release.
Start with the customer's work
A SaaS product is more than a website with a login. Customers need to get their work done, and you need to control access, manage accounts and support the product without changing records by hand.
We define the first complete workflow and the people involved before committing to a large roadmap. Existing software may cover some of what you need, and we say so when we see it.
The project runs like every project we take on, with a written scope and one fixed price, a demo every week, and an experienced engineer reviewing every change. See how a project runs.
The product and the tools to run it
Accounts and permissions
Who can see and change each record, including the boundaries between customer organizations.
Customer workflows
The important journey, including errors, interrupted work and recovery.
Billing and access
Plans, upgrades, failed payments and cancellation, when paid access is part of the product.
Integrations
Which system owns which data, and what happens when another service fails.
Operations
Admin screens, deployment, backups, monitoring and support, all written into the scope.
We run this kind of product ourselves. CrabGate takes payments through each organizer's own Stripe account and emails buyers, and KeySend checks each customer's Google Ads accounts every day. See our products.
A first release with a defined purpose
We can start with MVP development when the immediate goal is to put one useful product in front of users. The MVP scope is the first release, and the SaaS scope also plans how the service will be run and developed after it.
We agree the acceptance checks and separate launch requirements from later ideas. A feature list isn't an estimate until the uncertain dependencies have been checked.
An existing SaaS product can improve without a full rewrite
If the product is already in use, we review its behavior, data, deployment and access before changing it. We start with a release we can reproduce and the failures that matter to customers.
Our takeover, modernization and maintenance services cover inherited systems and ongoing product work. For an existing Rails application, see Ruby on Rails development.
What decides a SaaS estimate
Workflows, roles, integrations, data migration, billing rules and operating needs decide the work. Separation between customers and their data is designed for your real customer model from the start.
If you want to prepare, read how to prepare a software brief. It is optional. We work remotely, in English or Romanian, and we send a scope and price after we understand the product, never before.
Questions about SaaS products
Do you handle billing and subscriptions?
Yes, usually with Stripe in your own account. The scope covers plans, upgrades and downgrades, failed payments and cancellation, with tests that check access against the subscription state.
Can each customer company see only its own data?
Yes. We design the boundaries between customer organizations from the start, and the tests check them on every change.
Who runs the product after launch?
You decide. We can hand over with a runbook, or keep running it under a maintenance agreement. Hosting and paid services are billed to your accounts by their providers either way.
Do I need a full product roadmap first?
No. We start with the first complete workflow and the people involved. The roadmap can grow as customers use the product.
Related thoughts
-
MVP development cost: what belongs in the estimate
Compare MVP development estimates by user journey, integrations, acceptance criteria, ownership, and the costs that continue after launch.
-
Planning custom software development: scope and cost
Prepare a custom software development brief: users, workflows, integrations, scope, cost drivers, and acceptance checks before you ask for a proposal.
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
Describe the work your SaaS product will do for customers
Tell us who the customers are, the work they need to get done, and your timing. Mention user roles, billing or integrations if you know them already, and a budget limit if there is one.