01
Customer portals
Your clients see their status, documents, history and invoices.
Build · 01.2
Applications that survive daily use.
A demo has to work once, with clean data. An application has to work every day, with busy users and messy data. We build the second kind.
01 / What it is
What we mean by a web app.
Pick the one closest to yours.
02
Internal tools
Replace outgrown spreadsheets for operations, inventory, scheduling and approvals.
03
Booking and workflows
Processes with steps, states and rules: appointments, requests, intake and approvals.
04
Dashboards
Data people act on, not just charts. The hard part is deciding what goes on the first screen.
02 / Included
What an app build includes.
What separates an application from a demo.
Authentication and roles
Who can see and do what, modeled explicitly.
A real data model
Relationships, constraints and migrations in PostgreSQL. Mistakes here are the costliest.
Every state designed
Loading, empty, error, partial and overloaded states.
Tests where they pay
Automated tests for money, permissions and data integrity.
Audit trail
A record of who changed what and when. Adding it later costs more.
WCAG AA accessibility
Keyboard navigation and focus order.
03 / What to watch
What makes app work different.
Each risk, and how we avoid it.
×Complexity lives in the rules, not the screen count.
Rules, data and roles are written down before screens are designed.
×Requirements change once real users arrive.
An early clickable prototype and two-week adjustment blocks.
×Migrating existing data is usually the hardest week.
Migration is planned from the data model, not left to the end.
×Each new role multiplies permission checks.
Permissions are modeled in one place.
×The work shifts from building to running.
A monthly support agreement from launch.
04 / How it works
How it works.
How we usually work. The quote sets the real dates before work starts.
Model
Data, roles, rules and flows, written down and debated early. Deliverables: data model; flow and role map.
Prototype
A clickable main flow using real field names. Deliverables: clickable prototype; revised scope.
Build
Two-week iterations with continuous deployment to a staging environment. Deliverables: working app; releases every two weeks.
Launch and run
Data migration, user onboarding and monitoring, followed by a support agreement. Deliverables: live app; support agreement.
05 / Questions
Questions we get asked
Not with a fixed price from a general description. The first phase is modeling, which ends in a scope we can quote firmly.
Usually, yes, if the system has an API. If not, options include scheduled imports, files or database reads. We decide this at scoping.
You do, in your own accounts. Hosting and the database are usually inexpensive, and we document the setup.
Most clients move to a small monthly agreement after launch, which costs less than treating each change as a new project.
Yes. It's TypeScript with a conventional structure, written documentation and a handover session. No proprietary frameworks.
Tell us what you need built.
Describe it in a few lines. We'll reply with a plan, a timeline and a fixed quote.