Web apps, SaaS and MVPs
Web app development
A web app differs from a website because people do not read content — they do work: they create records, approve them, and see different data depending on their role. The decisions that matter are therefore not about design but about who can see and change what, how usage is measured, and what happens when the amount of data grows. We start from the smallest useful version that can genuinely be used, and expand only then.
Discuss a product ideaIn short: what a first version needs
A first usable version needs three things: one concrete scenario the product completes from beginning to end, a list of roles with clear boundaries, and a decision about which data is the source of truth. Everything else — notifications, reports, additional integrations — can arrive later without breaking the foundation. The most common mistake is building many features at once that nobody uses yet, which makes it impossible to tell which of them is actually needed.
When a web app is the right choice
- Several people do the same work and need to see different data according to their responsibility, rather than one shared spreadsheet.
- The process has state: a request moves through stages, someone approves it, and you need a history of who changed what and when.
- Data must be reachable from different places and devices without emailing files and losing track of versions.
- You plan to offer the product to customers as a service, so you need separate accounts, access boundaries and usage accounting.
When something simpler is enough
- One person handles a small amount of data – a well-structured spreadsheet is often the faster and cheaper solution.
- You only need a registration or enquiry form with no further work on the data – a website with a form covers that.
- A standard system already matches the process without major exceptions – configuring it is then cheaper than building your own.
Roles, data and boundaries
Roles are the first technical decision, because the data structure and security follow from them. The example below shows how visible data and permitted actions differ between product users. This is an illustrative structure to help prepare for a conversation, not a description of a specific client product.
| Role | What they see | What they can do and limits |
|---|---|---|
| Account owner | All data in their organisation, usage accounting and invoices. | Invites users, changes the plan, sees billing. Cannot see data belonging to other organisations. |
| Team member | Only the records and projects they are assigned to. | Creates and edits their own work records. Cannot change the plan, invoices or access rights. |
| Customer user | The status, history and documents of their own requests only. | Submits requests and comments. Cannot see internal notes or other customers’ data. |
| External partner | Only invited projects and the information needed for their work. | Completes assigned tasks with time-limited access. Cannot see invoices or other projects. |
| Administrator | System operation records, access-change history and errors. | Manages roles and restores data. Actions remain in audit records and are not anonymous. |
How the work runs
- 01
Clarifying the scenario
We choose one scenario that delivers value on the first day of use and describe it step by step with roles. This makes it possible to drop features that sound useful but have no real user.
- 02
Data structure and access
We plan the data model, role boundaries and how different customer accounts are separated. This stage determines what will later be easy to change and what will be expensive to change.
- 03
First usable version
We build a working version with real data and several users. The goal is not a demonstration but the ability to do real work and see where the process gets stuck.
- 04
Expansion and handover
Guided by actual use, we add integrations, reports and billing. We hand over the code, environments and documentation so another team could continue the product.
What drives cost and duration
- The number of roles and how much their visible data and permitted actions differ.
- Whether separate customer accounts and usage accounting are needed, or one organisation is enough.
- Integrations with external systems: the quality of their documentation and error handling.
- Billing logic: plans, limits, mid-period changes and refunds.
- Migrating data from existing files or systems and verifying its quality.
Worth considering before a conversation
- 01Which single job should the product complete from beginning to end in its first version?
- 02Who will the users be, and which data must be invisible to one of them?
- 03Where is the data kept today, and will it need to be migrated?
- 04Which systems will the product need to exchange data with?
- 05Will only your team use the product, or customers as separate accounts too?
Let us discuss a first version
Describing one process, its participants and the main obstacle is enough. Do not send credentials or real customer data — an anonymised example is a suitable starting point.