For product teams and agencies
User accounts, permissions, databases and business rules for web applications and portals.
Once a project needs customer accounts, staff roles, bookings, orders or approvals, it needs a backend. That’s where data is stored, rules are applied the same way every time, and work carries on after the visitor has closed the tab.
You mostly notice a backend when something goes wrong: a payment that’s taken but never recorded, a customer who can see someone else’s order, an import that stops halfway. We spend most of our time on the decisions that are expensive to change later, like how the data is structured and who’s allowed to do what.
Product teams adding features
You have a frontend team and need backend help for a new part of the product, such as accounts, billing or an admin tool.
Agencies building portals
Your client wants logged-in areas, staff dashboards or workflows that a CMS can’t handle.
Teams outgrowing spreadsheets
A spreadsheet, form builder or no-code tool has hit its limits, and the process needs a proper application.
Tables and relationships that reflect how your business actually works, with a plain-language explanation your team can follow.
Sign-in through an established provider or library, and permissions checked on the server for each request.
The logic that decides what happens, with input validation and clear error messages when something isn’t allowed.
Emails, imports and scheduled tasks that run separately from the page, and retry when they fail.
Error alerts and logs so problems are spotted early, and backups set up in your hosting account. We agree what’s needed for each project.
For most business applications we suggest a relational database such as PostgreSQL. It keeps the data structured and makes reporting easier. We’d only suggest something else for a specific reason.
We use a well-maintained library or a hosted sign-in service rather than writing our own. A hosted service costs more each month and ties you to it, while a library is more work to set up. We’ll explain both before you choose.
If only your own website uses the backend, keeping it inside the same application is simpler. If a mobile app or another company needs to use it, a documented API is worth the extra work.
Managed databases and queues cost more each month but need far less looking after, which usually suits smaller teams. We’ll show you the running costs before you commit.
Hiding a button doesn’t stop anyone. Each request is checked against what that person’s role allows. Agreeing this table early saves a lot of rework later. Pick a role to see what it can do.
Illustrative example
Checked on the server for every request. Hiding a button isn’t what protects the data.
| Role | View bookings | Create booking | Cancel any booking | Change prices | Export data |
|---|---|---|---|---|---|
| Customer | Own only | Allowed | No | No | No |
| Front desk | Allowed | Allowed | Allowed | No | No |
| Manager | Allowed | Allowed | Allowed | Allowed | Allowed |
| Accountant | Allowed | No | No | No | Allowed |
We work out the records, rules and roles with you and agree the data structure before building features.
The database, sign-in, environments and monitoring.
Each feature built all the way through, so it can be tried properly.
We test the permissions and rules where a mistake would be costly.
Existing data imported with a script we can run again if needed.
Notes on deploying, restoring backups and common support tasks.
Sign-in services, email providers and hosting platforms each have their own prices and limits. They’re your accounts and your running costs, so we list them before we build.
The full process, from first message to handover, is on How we work.
A regional logistics group, via its digital agency
A purchasing portal for a logistics group across Singapore and Malaysia: one place to request, approve and track every purchase, connected to the finance system.
The cost depends more on how many rules and user types the system has than on how many screens it has. If the idea isn’t settled yet, we often suggest a short paid workshop first, so there’s something solid to estimate.
After a first call, we send a written quote that says what’s included and what isn’t.
For new work we usually suggest TypeScript on Node.js with PostgreSQL. If you already have a backend in another language, tell us what it is and we’ll say honestly whether we’re the right people for it.
We only collect what the application needs, limit who can see it, and keep passwords and keys out of the code. Singapore’s PDPA puts obligations on the organisation holding the data. We’ll build with those in mind, but you should check your obligations with your own adviser.
Yes. We use widely known tools and document how the system works, so another developer can carry on.
We set it up in accounts you own, so you keep control of the servers and the bills.