Dashboards, client portals, internal tools and the unglamorous software a business actually runs on. Built on Next.js and Postgres, scoped in writing, and handed over with the credentials and the documentation.
Most web application projects start the same way: a spreadsheet that three people edit, a shared drive nobody trusts, and a process that only one person fully understands. It works until it does not, and the cost of the gap is paid daily in manual reconciliation nobody logs.
Who can see what is the hardest thing to retrofit and the easiest thing to get wrong. We model it before the first screen, and enforce it in the database rather than only in the interface.
A real relational schema on managed Postgres, with migrations in version control. No proprietary backend you cannot leave, and no data model that only makes sense inside one vendor's console.
Next.js App Router with server components, so the dashboard loads with data already in it instead of showing five spinners while the browser fetches. Heavy tables paginate on the server.
Who changed what and when, stored immutably. Every business application eventually needs this, and adding it afterwards means backfilling history you never recorded.
CSV out, webhooks, and API access, because the application will have to talk to your accounting, your CRM or your warehouse eventually. Designed as an assumption, not an afterthought.
Repository, environment variables documented, deployment pipeline, and a written runbook. You can hire someone else tomorrow and they can pick it up.
Most web application overruns trace back to the same handful of omissions. None of them are exotic, and all of them are cheaper to decide before development than during. Read these as the questions we will ask you, so you can answer them before anyone quotes.
Hiding a button is not a permission. If the underlying route still returns the data, anyone with the browser console can read it. Real permissions are enforced where the data lives, which in practice means row-level policies in Postgres or an authorisation check on every server action. Retrofitting this onto an application that assumed everyone sees everything is close to a rewrite, which is why we model roles before screens.
Almost no business application should truly delete records. Invoices, audit trails and anything with a legal retention period need soft deletion, and users need to understand the difference between archiving something and destroying it. Decide the policy per entity early, because changing your mind later means the deleted rows you now want are already gone.
There is nearly always existing data, and it is nearly always messier than described. Duplicate customers, dates in three formats, a status column with eleven distinct spellings of the same four states. Cleaning it is real work and it belongs in the quote. The alternative is a clean new system populated with the same mess, which erodes trust in the tool within weeks.
Background jobs fail, payment webhooks arrive twice, and an integration will go down. An application without an error path silently loses work and nobody notices until a customer complains. Deciding early who gets alerted and what the retry policy is costs an hour of conversation and saves the incident where three weeks of records quietly did not sync.
Every internal tool gets a request for a number the schema was not designed to produce. You can prepare for this cheaply by recording events rather than only current state, so history exists to query later. It is a small design decision on day one and an impossible one afterwards, because you cannot query data you never stored.
A website shows content. An application holds state that people change, which means concurrent edits, permissions, history, and consequences when something goes wrong. The difference shows up in the parts you cannot see: what happens when two people edit the same record, what a user sees when their permission is revoked mid-session, and whether you can reconstruct who did what six months later. Those decisions are the project.
Next.js with TypeScript on the front and Postgres behind it, deployed either on managed hosting or on your own infrastructure. You should care for exactly one reason: how easily you can hire someone else. All three are mainstream and well documented, so replacing us is a normal recruitment problem rather than a search for the two people who know a niche framework.
Usually yes, and the answer depends on what they expose. A documented REST or GraphQL API is straightforward. A vendor with a partner-only API means a procurement conversation before development. A system with no API at all means scheduled file exchange or database-level integration, both of which work but should be scoped honestly rather than promised as real-time. Tell us what you run and you get a specific answer.
Quoted per project, on request. The variables that matter: how many distinct entities exist in your domain model, how many roles need different views, whether integrations are involved, whether the data has to be migrated from something existing, and whether the process is already documented or has to be discovered by interviewing the person who holds it in their head. That last one is routinely underestimated.
That is a normal and reasonable outcome, and the project is built for it from day one. You own the repository and the infrastructure accounts throughout. At handover you get documented environment variables, the deployment pipeline, and a written runbook covering how to deploy, how to restore a backup, and what breaks first under load. We would rather you leave cleanly than stay because leaving is painful.
No. Everything is written and asynchronous. You send the brief and the process you want to replace, we send back questions and a scoped proposal, and you get preview environments as work lands. We do not run calls, and it has not cost a project yet. It also means the decisions are written down, which is worth more than it sounds when someone asks in month six why a thing works the way it does.
Send the spreadsheet, the workflow, or a description of what your team does by hand. You get a scoped quote and a written reply within one business day.
Request a quote →