Custom web application development built for daily use.
SaaS products, customer portals, booking and ordering systems - the browser software a business runs on. We design the data model, build the backend, the API and the interface, deploy it, and stay for what only shows up once real users arrive.
- One team for the database, the API and the interface - no hand-off gaps.
- Every customer sees only their own data - enforced by the database, not by hope.
- Live updates: when one person changes something, everyone else sees it.
- Typed end to end: TypeScript, versioned migrations, a documented API.
Where the real engineering lives
A web application is not a website with a login. It holds state that matters - orders, invoices, permissions, audit trails - and many people change it at once. Most of the engineering lives where nobody takes screenshots: the data model, the permission rules, and what happens when two people edit the same record.
We build web apps the boring, durable way: PostgreSQL as the single source of truth, a typed API in front of it, a fast server-rendered interface on top, and background jobs for anything that should not make a user wait. The API is written down before the code, so your mobile app, your partners and your own integrations build against something stable.
New products from the first schema onwards, or apps another team started that need to become trustworthy - we take on both, from Ugljevik and Vienna, remotely with teams across Europe.
How it works
What a good web app feels like
Three things separate a web app people trust from one they work around. Here they are in a customer portal for a wholesale supplier.
-
A customer logs in and sees their own orders, prices and invoices - nobody else’s. Your staff see everything. The rule lives in the database, so no screen can forget it.
-
When the warehouse marks an order as shipped, the customer’s screen updates the same second. No refresh button, no “did you get my email?”.
-
Ten users or ten thousand: pages answer just as quickly, because slow work happens in the background and extra servers start on their own when it gets busy.
In practice
Illustrative scenarios - the kind of work we take on, not client case studies.
Turning an internal tool into a SaaS product
- The problem
- A company built a scheduling tool for itself, and other businesses in the industry want to pay for it. The code assumes a single customer everywhere.
- What we build
- Tenants done properly: every customer’s data separated in the database, per-tenant settings, self-service sign-up with card billing, and the original company migrated in as tenant one. Plus an admin console, so support never touches the database directly.
- TypeScript
- PostgreSQL RLS
- Stripe
- SvelteKit
- Docker
A customer portal on top of an existing ERP
- The problem
- Customers phone in to ask about order status, invoices and delivery dates. The answers live in an ERP they can never be given access to.
- What we build
- A web portal with its own login that reads from the ERP through a narrow API, caches what rarely changes and shows each customer only their own documents. Reorders go through a queue, so a slow ERP never freezes the portal.
- SvelteKit
- Node.js
- REST API
- Redis
- BullMQ
A public API for partners
- The problem
- A logistics company wants partners to book shipments and track parcels from their own systems, but today everything goes through email and an internal tool that has no API.
- What we build
- A versioned REST API with an OpenAPI spec, API keys per partner with their own rate limits, signed webhooks for status changes and a sandbox. Client libraries and reference docs are generated from the same spec, so the documentation cannot drift from the behaviour.
- Go
- OpenAPI 3.1
- PostgreSQL
- Redis
- Prometheus + Grafana
What you get
- Data model and database schema with versioned, reversible migrations
- A documented API (OpenAPI or GraphQL) your other apps and partners can build against
- Roles and permissions enforced in the database, plus an audit log of who changed what
- Live updates where people work together, background jobs for everything slow
- Admin screens for your team, so support never needs the database
- Sign-up, billing and subscriptions for SaaS products
- CI/CD and infrastructure as code - staging and production built the same way
Typical stack
- TypeScript
- SvelteKit
- React / Next.js
- Node.js
- NestJS
- Go
- PostgreSQL
- Redis
- WebSockets
- OpenAPI
- Docker
- Playwright
- Stripe
Questions people ask
Your question is not on the list? Ask us directly - we reply within two working days.
Ask a questionHow much does custom web application development cost?
Mostly on three things: how many user roles and workflows the app has, how many outside systems it talks to, and how much existing data must be migrated. Send us a short description; we reply within two working days with a link to a 30-minute intro call, then send a written plan with a fixed-scope estimate, broken down by feature.
How long does it take to build a web app?
Timeline follows scope. We prefer a usable first version early over one big launch: the work is split into slices that each end in something on staging you can click through, typically every one to two weeks. The written estimate shows the timeline per slice.
Which technology do you use - and why not a no-code tool?
By default TypeScript with SvelteKit or React, Node.js and PostgreSQL - well known, fast and easy to hire for. We adapt to an existing .NET, PHP or Python codebase when that makes more sense. No-code tools are fine for prototypes; they get expensive once you need custom permissions, integrations or many users.
How do you keep customers’ data apart in a SaaS product?
Every row carries the customer it belongs to, and the database itself filters every query by the signed-in customer (row-level security) - including a query someone writes in a hurry. Automated tests log in as one customer and try to read another’s data; if that ever succeeds, the build fails.
Can you build the API for our mobile app or partners too?
Yes - most web apps we build have a documented API at their core, and the browser interface is just its first client. A mobile app, a partner integration or your own scripts use the same API with their own keys and limits.
Have a process that outgrew its spreadsheet?
Tell us what the app needs to do and who will use it. We reply within two working days with a link to a 30-minute intro call, then send a written plan and a fixed-scope estimate.
Start a project