01 · What we do
Web and mobile applications
Web platforms, mobile applications and the internal tools your staff use, all reading one API over one database.
We build the interface a customer uses and the API underneath it. Customer web, iOS and Android, and the back office your staff work in are treated as one engagement, because they share a domain. A rule about who may refund an order lives once in the API, where all three read it. Node, TypeScript, React and Next.js, handed over in your repositories.
Empty states, timeouts, and a declined payment are handled before the launch date. Web and mobile consume one API, so a change to a rule is made in one place.
What this covers
Customer web platforms
Browser applications for daily use. Accounts, the main workflows, and the empty and error states. Node, TypeScript, React, Next.js.
Handed over in your repositories, running in your environment. The design log records what was chosen and what evidence would change it.
Mobile apps for iOS and Android
iOS and Android talking to the same backend as the web product. Authentication, the core workflows, and push notifications where they are justified.
Mobile talks to the same API as the web product, so there is one source of truth for a rule.
Internal tools and back offices
Screens for operations, editors, and support. Same data as the public product. Permissions match the job.
Internal tools get the same standard as the customer app: measured, handed over, with a runbook.
Dashboards and reporting portals
Reporting portals where the query behind each figure is documented and readable.
Filters, export, and the no-data-this-week state are in scope from the start. Each figure names the query behind it, so a reader can check where it came from.
APIs and integrations
HTTP APIs and the connections to authentication, payments, search, and CRM. Versioned, authenticated, with errors a caller can handle.
Timeouts, retries, and idempotency keys on anything that writes. The integration is tested against a sandbox and against one production failure we have already seen.
E-commerce and booking systems
Catalog, cart, booking, payment, confirmation. Declined cards, sold-out slots, and abandoned carts are handled in the first release.
Stock and bookings are the source of truth in your database. The payment provider stays a dependency, and your database stays the system of record.
Deliverables
The application
Web, mobile, or both, in your repositories.
An API you own
Versioned and authenticated, consumed by every client.
Working integrations
Auth, payments, search, or CRM, tested against a sandbox and one real failure.
CI and deploys
A pipeline your engineers run without us.
Runbook and design log
What was chosen, and what evidence would change it.
Example
Example · Web application
A browser application for an editorial desk
A Node and TypeScript backend with a browser UI. Editors ask grounded questions, read passages with citations, and work in a product built for a specialist desk.
The write-up covers retrieval. The delivered product was the application: accounts, a working interface, and citations on screen.
Read the write-up