Scenario · SaaS & B2B tools

Building a Jira-style SaaS for customer onboarding: a B2B MVP from first spec to first tenant

Want to build a SaaS like Jira for customer onboarding? A Berlin founder's B2B MVP: multi-tenancy, SLA timers, audit trail, what got cut and what it cost.

By Akash Bansal, founding engineerUpdated 4 November 20268 min read

Illustrative scenario. The founder in this story is a composite, not a real client. The process, costs and decisions are drawn from builds I have done; names and business details are invented to show how a build like this typically goes.

"I want to build a SaaS like Jira" is usually not what a founder means. They mean: Jira-style boards and stages, but for one specific workflow that Jira handles badly, with the people outside the company able to see their part of it. That is a real product. A Jira clone is not.

This story follows a composite founder building a customer-onboarding SaaS. My evidence is KAF OS, a customer-onboarding SaaS I built: multi-tenant, with SLA-tracked stages, an immutable audit trail and a three-step activation (create the company, assign a workflow, assign an agent). The decisions below come from building that.

The founder and the starting point

Call her Lena. She spent six years in customer success at a Berlin B2B payments company, the last two leading onboarding for enterprise customers. Each new customer went through the same stages: contract signed, compliance documents, technical integration, test transactions, go-live. Each stage had an owner on both sides, a deadline, and a habit of slipping.

Her team tracked it in a Jira project, a shared spreadsheet the customer could see, and a lot of email. The customer could never see the Jira board, the spreadsheet was always out of date, and nobody could answer "how long do we usually wait on the customer at the compliance stage?" She left to build the tool she had wanted, to sell to other B2B companies with the same problem.

Should you build a SaaS like Jira, or buy one?

If you only need this for your own team, buy. Jira's free plan covers up to 10 users (Atlassian). Purpose-built onboarding tools exist too: Rocketlane lists $49 per user per month on its Standard plan, billed annually, with a five-seat minimum. For an internal team, a $250-a-month tool beats a $25,000 build every time.

Building makes sense when the software is the business. Lena was not solving her old team's problem; she was selling to companies that could not justify Rocketlane's seat minimum, or that needed an EU-hosted tool with compliance stages built in. That gap is the product. The build only has to be good at that one workflow, which is why it can be an MVP and not a ten-year platform.

Who built it, and why

Lena had a German agency quote for €90,000 over five months, and a cofounder conversation with a former colleague that stalled on equity. She chose a founding-engineer build: one senior engineer accountable for architecture, backend, frontend, cloud setup and security, on a fixed quote after scoping. On my builds the client owns the repository and every cloud account from day one, gets a working demo every week, and gets written design docs and a handover. For a B2B SaaS that will go through customers' security reviews, those design docs turn out to matter a lot.

Best for: a founder with domain expertise and two or three design partners lined up. Not for: someone who has not yet talked to ten companies about the problem. If you are still comparing options, I wrote up technical cofounder vs founding engineer vs agency.

What got cut from v1

Lena's first spec was 40 pages and read like Jira's feature list; a good PRD for an MVP fits on two to four. The scoping week cut it to the onboarding loop: a vendor company sets up a workflow, starts an onboarding for a customer, both sides move it through stages, and everyone can see where it is stuck.

That single report was the one thing Lena could never get from Jira, and it became the demo that sold the first design partner.

The build, week by week

1. Week 1: scoping and the data model. Tenants, users and roles, workflow templates, onboardings, stages, events. Every stage transition and who may make it, written down.
2. Week 2: tenancy and auth. A tenant ID on every row, enforced by database row-level security as well as application code, so a missed filter in one query cannot leak another company's data.
3. Week 3: activation flow. The same three steps I used in KAF OS: create the company, assign a workflow, assign an agent. A new tenant reaches a live onboarding in minutes, which is what you want a trial user to feel.
4. Week 4: workflow templates and stages. Ordered stages with an owner side (vendor or customer), a checklist and required documents.
5. Week 5: SLA timers. Target duration per stage, a clock that pauses while waiting on the customer, and warnings before a breach.
6. Week 6: audit trail. Append-only event log for every change, written in the same transaction as the change itself.
7. Week 7: customer view and notifications. Magic-link access for the customer's contacts, email on stage changes and SLA warnings.
8. Week 8: billing, the stage report, and the first design partner onboarded in production.

The three parts that are harder than they look

Multi-tenancy

Multi-tenancy means one running system serves many customer companies, with each company's data walled off from the others. It is cheap to do on day one and expensive to add later. The approach I default to is the simple one: one database, a tenant ID on every table, and the database itself refusing cross-tenant reads. Separate databases per tenant sound safer and are much more work to operate. Save them for the enterprise customer who demands it in the contract. The other SaaS foundations, activation and billing among them, are in the guide to building a SaaS product from scratch.

SLA timers

"Stage must finish in five business days" hides a lot. Whose business days? Germany's public holidays differ by federal state, and Lena's customers were across the EU. Does the clock pause when the stage is waiting on the customer? The answer we settled on: each tenant sets a working calendar, and the clock only runs while the stage is on the vendor's side. Computing SLA state when you read it, rather than with scheduled jobs, kept it correct when calendars changed.

An immutable audit trail that still meets GDPR

Here two requirements collide. Compliance wants a history nobody can edit. GDPR gives people a right to erasure. The way through is to keep the log append-only but store no personal data in it: events reference pseudonymous IDs, and names and emails live in a separate table that can be deleted or anonymised. This pattern is called pseudonymisation; a related technique, deleting a per-person encryption key, is called crypto-shredding. Lena's customers were controllers and she was their processor, which also meant a data processing agreement under GDPR Article 28 and EU hosting, both of which came up in the first sales call.

What the build and running costs look like

The build is a fixed quote after scoping. My MVP builds start at $15,000; a multi-tenant B2B scope like this is my rough estimate of $20,000–$30,000, depending mostly on roles, the customer view and billing. For a rough range on your own B2B scope, try the app cost calculator. Running costs at around ten paying tenants on €300 a month:

B2B SaaS is cheap to run and expensive to sell. The line missing from this table, and the largest one, is Lena's time on sales calls and security questionnaires.

What went wrong

• The first design partner wanted SSO in week two of the pilot. We held the line: SSO went into the contract for month three, not into the MVP. The pilot went ahead on magic links.
• Templates changed under live onboardings. Editing a workflow template should not reshuffle onboardings already in progress. Each onboarding now keeps a snapshot of the template version it started on.
• The security questionnaire arrived before the contract. Eighty questions about encryption, backups, access control and incident response. The written design docs answered most of it, which is the strongest argument I know for writing them during the build.
• "Waiting on customer" was disputed. Customers did not like a red timer pointing at them. The customer view shows the stage and the next action, not the blame.

What launch looked like

There was no public launch. Lena onboarded one design partner, then two more, each on a discounted annual contract in exchange for weekly feedback. The stage report from the first partner, showing how much of each onboarding was spent waiting on which side, went into her sales deck. Only then did she open self-serve trials using the three-step activation.

Checklist if you want to build a workflow SaaS

1. Name the one workflow. If the answer is "like Jira, but for everything", stop.
2. If it's only for your own team, buy a tool.
3. Line up two or three design partners before the build starts.
4. Build multi-tenancy and the audit trail on day one; they can't be bolted on.
5. Define SLA rules in writing: calendars, pauses, which side owns each stage.
6. Keep personal data out of the audit log.
7. Defer SSO, custom fields and integrations until a paying customer makes them a condition.
8. Get design docs written during the build; your first security review will need them.
9. Own the repository, the cloud accounts and the billing account from day one.

For budgeting, see the 2026 MVP cost breakdown and how long an MVP takes. If you have the domain expertise and the design partners, and want one engineer accountable for the whole product, this is the kind of build I do; here is how I work and what it costs.