• Applications & Products · Next.js

SaaS platform: from the first paid user to a system that pays for itself

The development of a SaaS platform fails not on the code, but on the question "what exactly will be paid for". Therefore, we start not with technologies, but with analysis: which scenario closes the service, which should be in the first version by design, and which is deliberately left for later. We've built three of our own products based on this model—a description rewriting platform, a chatbot platform, and a licensing service—and each one has taught us something that's cheaper to learn from someone else's experience.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
The term of the first version
30-120 working days depending on the number of scripts
after a free audit
Price
30
Guarantee

days after project sign-off

30-120
The term of the first version

working days depending on the number of scripts

after free analysis of the idea
Cost
three own products in the market
Tested on myself
first server response 220 ms
Our fastest SaaS
payment model chosen before the start
That solves half of the architecture
Who it's for

Situations where this service delivers results

Scenario 1 of 4

There is a manual service that you want to turn into a service

You already do something with your hands for customers and you see that the process is repetitive. This is the healthiest start: the demand is confirmed, it remains to be understood which part of the work can really be given to the machine, and which part only looks automated.

We'll review your situation in a free audit
Cases

Tasks and results in numbers — all metrics measured by us

Ukrainian SaaS platform for rewriting product descriptions of online stores

Task
Build a service that imports catalogs from marketplaces, rewrites descriptions with an SEO structure, and sells it on a transparent pay-per-use model.
Solution
Application on Next.js with import of directories in four formats, customization of text style, public part and markup for search. Payment — for actual use, with balance replenishment.
Result
Measured on 07/31/2026: First server response of 220 ms at 141 KB of HTML, the fastest response of the 16 portfolio sites measured at that time. 8 public pages, JSON-LD markup with SoftwareApplication, Offer, Organization, WebSite and FAQPage, working PWA manifest.

own chatbot platform for Ukrainian e-commerce

Task
Make a service in which the bot sells in the messenger and in the widget, accepts payment, pulls data from the store catalog — and shows the owner not the "number of dialogues", but the contribution to income.
Solution
A three-part monorepository: a backend on Fastify with a script engine and a gateway to language models, a client office on Next.js and a separate marketing landing page. Payment and shipping are integrated as part of the sales scenario, not as an external link.
Result
Measured on 08/02/2026: the office is in progress, the first server response is 227 ms. 603 TypeScript files, 164 commits in 27 days of work on the first version.
What's included

Complete list of work and what you get as a result

  • The working first version, in which one key scenario is closed - from registration to the result that is paid for.
  • Registration, login, roles and access restrictions. For service with companies — separate workspaces.
  • Payment model for you: subscription, pay-as-you-go or license with key.
  • Personal account with balance, limits and history of operations - without this, the user does not understand what he is paying for.
  • Processing webhooks of the payment system so that access is opened upon the fact of payment, and not upon returning to the site.
  • Admin for you: users, payments, manual operations, returns. Without it, every non-standard situation becomes a task for the developer.
  • Event analytics: you can see how many people went from registration to the first useful action and where exactly they fall off.
  • Transactional letters: confirmation, reminders, notices about the end of the period.
When this service isn't right

What's not included — so there are no surprises at delivery

  • Marketing and attracting first users. We will make a product, but bringing people is a separate job and a separate competence.
  • Legal drafting of the offer, privacy policy and return conditions: the texts are written by a lawyer, we embed them.
  • Mobile apps in stores are a separate project with their own publishing rules.
  • Round-the-clock support for users of your service.
Process steps

Transparent stages with approval at every step

Total duration:30–120 days

  1. Analysis of the idea

    2-3 days

    We find out what will be paid for, and reduce the idea to the first version. The payment model is decided here.

  2. Scenarios and data

    5–10 days

    We break down the user's key path into steps and states, design a data model for it.

  3. The core of the product

    15–50 days

    Registration, access, the main script is what people will come for.

  4. Payment and limits

    5–20 days

    Payment connection, webhook processing, account with balance and history.

  5. Admin and analytics

    5–15 days

    Manage users and payments for you, events to understand where they fall off.

  6. Launch and first users

    3–10 days

    We bring it to production, look at real behavior and correct what prevents us from getting to the payment.

Instead of a price fork — a free analysis of the idea

We are not looking at technology, but at what you will be paid for: what scenario closes the service and what should be in the first version.

What we measure

  • Who pays and for whatis there a moment in the task for which a person will give money, or is it "convenient, but free is also the norm"
  • Minimal versionwhat to remove from the plan so that the first paid user appears earlier
  • Payment modelsubscription, pay-per-use or license - half of the architecture depends on it
  • What are they already using?which tools close this task now and why people will leave them
  • What will have to countlimits, quotas, balance balance - this is the most frequent hole in the first versions

What you get

  • a list of scripts of the first version and what is deliberately left for later
  • scheme of the payment model with what will have to be calculated
  • evaluation of works with a breakdown by stages
  • an honest answer if the idea does not attract a paid product

Timeline: 2-3 working days

Why is it free

Half of the product ideas after analysis turn into something else or are shelved. Knowing this before paying for development is cheaper for everyone.

What's next

You receive a written scheme and an estimate. Then you decide for yourself - the analysis does not oblige you to anything.

Short form: your contact and site URL

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • European clients

    Among our work — projects for Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

Did not find your case?

Describe how it works on your side — we will tell you whether “SaaS platform development” fits and what it means in your situation. No brief and no call: one question, one answer.

What affects the price

Why two seemingly identical tasks are priced differently

  • Number of scripts in the first versionOne closed script is the base. Each subsequent one adds not only screens, but also states that the system can find itself in; it is states, not screens, that eat up time.
  • Payment modelOne-time payment is the easiest of all. Subscription adds renewal, cancellation, and renewal. Paying for usage is the most difficult: you need to count the balance, not let it go into the red and show it clearly to the user.
  • Licensing with installation on someone else's serverA separate circuit: issuing keys, linking to a domain, checking activity, continuing. Technically, this is almost the second product next to the main one.
  • MultitenancyService for one person and service for companies with roles and shared data are different architectures. It is more expensive to convert the first into the second later than to lay down immediately, so it is decided in the analysis.
  • Processing of large volumesIf the service accepts files or directories, queues, retries after failures and showing progress appear. This is often an underrated part.
  • Readiness of content and rulesRates, limits, letter texts and return conditions must be decided before development. When they are "refined on the fly", the term grows unpredictably.
Technologies & integrations

What we build on and what it connects to

Stack

  • Next.js
  • TypeScript
  • Fastify
  • PostgreSQL
  • Prisma
  • Supabase

Integrations

  • Stripe
  • LiqPay
  • WayForPay
  • monobank
  • Resend
  • PostHog
Own development or designer

How this option differs from the alternative

Start speedslower: this is development
Payment modelany, including usage fees and licenses
What will happen to thousands of usersdepends on the architecture, we lay it down
Who owns the product?to you: your code and data
What we need from you

We can't start without this — best to prepare in advance

  1. describing the task in the words of the future user, not in terms
  2. how this problem is solved now and what is annoying about that solution
  3. payment model, if it is already selected
  4. are there people willing to try the first version
  5. tariffs, limits and texts of letters — or readiness to solve them before the start

If something is missing — let us know, we'll help you gather it or do it as a separate task.

FAQ

Most frequently asked questions — with concrete answers

Where to start if the idea is still raw?

From the question of "who will pay and for what", and not from the choice of technologies. During analysis, we often do not add functions, but remove them: most ideas contain three or four scenarios, one of which is worth the money. If there is no such scenario at all, it is better to hear it in two days than in six months.

How long does the first version last?

From 30 working days, if the scenario is one and the payment is one-time. Up to 120 if you need tariffs with limits, workspaces for teams or licensing with installation on someone else's server. Our own chatbot platform reached the desktop in 27 days and 164 commits — but this is a product in which we ourselves are both the customer and the executor, that is, without coordination.

Subscription or Pay Per Use?

Depends on how a person feels the value. The subscription is clear when the service is used constantly. Pay-per-use is fairer where the load is uneven: in our description rewrite platform, a person pays for processed goods, and this removes the question "I haven't logged in for a month, what's the money for". Technically, the second model is more difficult: you need to count the balance and not let it go into the red.

What are limits and why is there so much talk about them?

This is the most frequent hole in the first versions. As long as the user is alone, no one notices that the system does not know how to say "you have run out of balance" in the middle of a long transaction. As users grow, it turns into refunds and complaints. Therefore, the limits are designed together with the payment model, and not added afterwards.

Is it possible to do it on the constructor?

It is often possible, and we will be honest about it. The designer wins as long as your script matches what he can do and as long as the pay is standard. Own development is justified when payment for use, license with installation on someone else's server is required, or when the product should remain yours — with code and data, and not live inside someone else's service.

Who will develop the product after launch?

Either we or your developer — the code and data are yours. SaaS differs from a website in that the work does not end after launch: real users show every week what is done inconveniently. It should be included in the plans immediately.

Do you do licensing for client server installation?

Yes, and we made such a circuit for our own product: issuance of keys, binding to the domain, verification of activity, continuation, connection of the license with the client's card in CRM. Technically, it is almost a second product next to the main one, so it is counted separately.

What about analytics?

Minimum — path events: registration, first useful action, payment. Without them, it's not clear why people don't pay: it's one thing when they don't get the product, it's quite another when they get there and don't see the value. These are different problems with different solutions.

Let's start with the analysis of the idea, and not with the estimate

Describe what task the service should close and how it is being solved now. We will return in 2-3 working days with a list of scenarios of the first version, a payment scheme and an assessment by stages. If the idea does not attract a paid product, let's say so in the first email.

From measured casesMeasured on 08/02/2026: the office is in progress, the first server response is 227 ms

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.