An internal system for a company
We move the work out of spreadsheets and chat threads into one system: documents from data, access rights, change history. Starts with a free review.
30–120 days
Development
Web Application and Platform Development: MVPs, SaaS, Internal Systems
Web application development starts from one distinction: a website tells, an application does the work. There are four kinds of tasks here, and they barely overlap: testing an idea before you invest in it; selling access by subscription; moving internal work out of spreadsheets into a system; letting clients book on their own while you sleep. Each one starts from a different question, and mixing them up is expensive: the first version of a SaaS product and the first version of an internal system only look alike from the outside. So we first work out what exactly has to work in version one and what will deliberately stay out of it. The first review of your task is free. Before it, any estimate would be made up.
How it works
What building an application consists of and how we run it in stages
Goal and scenarios
We write down who will use the application and which actions they need, so nothing extra gets built.
Building in parts
We build the application in working pieces and show them along the way, so edits come before the finish, not after.
Acceptance and handover
The result is tested and handed over by an act, and the code and access pass to you.
The format of the application depends on the audience and goals. We explain the choice and its reasons during the review, before any estimate or contract.
- Task types
- 4
- MVP, subscription platform, internal system, online booking
- First review
- Free
- 1–3 business days, no commitment on your side
- Code ownership
- Transfers to you
- after full payment, together with the repository and access credentials
- Warranty
- 30
- days
- from the date the acceptance act is signed; bugs on our side are fixed free of charge
MVP for a startup
The first version of your product, built to test demand rather than to look complete. Idea review, analytics from day one and an honest now-or-later scope line.
30–60 days
Online booking for services
The client picks the specialist, service and time themselves, with a reminder the day before and protection against double booking.
15–45 days
SaaS platform development
We build web services people pay for regularly: subscriptions or pay-per-use, a user account with limits, billing and analytics. We show it on our own products.
30–120 days
Who it's for
Situations where this service delivers results
Scenario 1 of 4
You have an idea, but nobody has seen demand for it yet
The most expensive mistake here is building a complete product and only then finding out nobody uses it. What you need is a first version built around one question: do people take the action the whole thing was started for? Then, after launch, you will have something to judge whether it worked.
We'll review your situation in a free auditScenario 2 of 4
The work lives in twenty spreadsheets and one person's head
It began with one spreadsheet, then a second for another task, then agreements moved into chat threads. This holds up longer than you would expect, and it always breaks at the same moment: when that one person is on vacation. An internal system brings it all into one place, with a change history.
Scenario 3 of 4
Clients book by phone, and half the requests get lost in the evening
The decision to book comes after work, before bed, on the subway. That is exactly when the receptionist isn't answering, and people don't wait until morning: they go wherever they can press a button. Online booking covers the part of the day you currently can't see at all.
Scenario 4 of 4
The product has to sell itself, by subscription
Failure here rarely comes from the code. It comes from the question of what exactly people will pay for. So the review starts with the scenario the service covers, and with which parts of the idea belong in the paid tier and which stay free so people have time to reach the value.
What's included
Complete list of work and what you get as a result
- A review of the task before work begins: which of the four types you actually need, and whether you need an application at all. Sometimes the task is solved by extending your existing website
- A list of what goes into the first version, and separately what is deliberately left for later: without that split, the scope keeps growing indefinitely
- A working application with an admin area where you manage the data yourself, without asking a developer for every change
- Repository, domain, hosting and analytics registered in your name: the access is yours from day one rather than handed over at the end
- Technical documentation on how the application is deployed and updated, so the next developer doesn't have to start by deciphering someone else's code
- A metric that will show after launch whether the idea works: leads, sign-ups, completed bookings, depending on the task
- Handover under an acceptance act and a 30-calendar-day warranty on the work performed
Process steps
Transparent stages with approval at every step
Task review
We find out what has to happen in the application and who will use it: an outside client, your employee, or both. This is also where it becomes clear which of the four types it is, and whether the task can be solved more cheaply without a separate product.
Scope of the first version
We write down what is in, what is out, and why. This is the most important document in the project: it is where the task stops growing. At the same time we agree on the metric we will use after launch to measure whether it worked.
Development with interim demos
We work in increments and show progress in a live environment rather than in descriptions. You see interim results and can change direction while it is still cheap, not after delivery.
Launch and handover
We move the application to your hosting, connect analytics, hand over access and documentation, and sign the acceptance act. The 30-calendar-day warranty starts that day.
When this service isn't right
What's not included — so there are no surprises at delivery
- Promises that the product will find users: we are responsible for it working and being measurable, while demand is tested by the market
- Mobile apps for the App Store and Google Play: that is separate work with its own release cycle
- Filling the system with data or migrating your spreadsheet records if they aren't in an importable shape: that is a separate scope, and it only becomes clear after we look at the files
- Projects with no one accountable on your side: in an application the client decides on the scenarios, and without that the project stalls
- Timelines quoted before the scope is reviewed: a two-week first version and a two-month first version are described in exactly the same words
FAQ
Most frequently asked questions — with concrete answers
Do I need an application, or will a website do?
It comes down to one question: does the user need to read something or do something? Read — that's a website. Take an action that changes data (book an appointment, start a subscription, move an order through stages) — that's an application. The line isn't always obvious, and sometimes the task is solved by extending your existing site. If that's your case, we'll tell you so at the free review.
Which of the four types is mine?
If you are checking whether there is demand for an idea, it's an MVP. If you sell access by subscription, it's a platform. If you are bringing order to your own processes and the users are inside the company, it's an internal system. If clients need to choose the time and the specialist themselves, it's online booking. When a task looks like two types at once, that almost always means the first version should be one of them, with the second coming as the next stage.
Why can't you give me a timeline right away?
Because tasks with the same name differ many times over: an “internal system” can be request tracking on three screens, or a system with roles, approvals and data exchange with 1C. We quote the timeline in business days after the review, broken down by stage, and fix it in the contract. Before the review, any number would be made up.
What happens if the idea turns out not to work after launch?
That's a normal outcome, and it's exactly what an MVP is built to reveal. That's why we agree before the start on the metric that will show it; otherwise, after launch, you'd be arguing over guesses. The data, code and access remain yours whatever conclusion you reach.
Who will maintain the application after delivery?
That's up to you. The 30-calendar-day warranty applies either way: bugs on our side are fixed free of charge. After that you can take ongoing support from us or hand the project to your own developer. We give you the repository and documentation on deployment and updates precisely so that you have this choice.
Do you lock clients in with your technology?
No, and you can verify it: the domain, hosting, repository and analytics are registered in your name from day one, and ownership rights to the code transfer to you after full payment. Nothing we build lives on our accounts. Otherwise you couldn't leave even if you wanted to.
Can we start small and expand later?
Yes, and with applications this is almost always better than trying to anticipate everything up front. The first version should confirm that the solution works for your case at all; extending is cheaper than reworking what turned out to be unnecessary. During the review we split the task into “now” and “later”.
What is a PWA, and can it replace a mobile app?
A PWA is a web application that can be installed on a phone from the browser: an icon appears, some features work offline, and notifications come through. You don't have to publish it in the App Store or Google Play, and every user gets updates immediately, without app store review. For booking, a client account or an internal system, this is usually enough. It isn't enough when you need deep access to the device or a presence in the app stores specifically. We have no native projects like that in our portfolio, and we won't present them as something we specialize in.
What do you build web applications with?
Most often TypeScript: Next.js for the interface and server side, PostgreSQL as the database, Prisma to work with it, and a separate Fastify service for high-load APIs. The agency's own system is built on this stack too. The choice isn't dogma: if you already have code in another technology and a developer who knows it, it makes more sense to continue with it. More important than the language is that the repository, server and database are registered to you, so any developer who knows the stack can pick up the application.
Not sure which service is yours?
Describe the task in your own words — we will tell you where to start and whether you need what you came for. If you do not, we will say so.
- Reply within 2 hours
- No commitment
- We work under a contract