TypeScript and Node.js
APIs, background jobs and integrations that share types with Next.js and React front ends. A field renamed on the server shows up as a build error in the browser code, not as a bug in production.
Capability 01 · Architecture & APIs
Back-end systems designed before they are built.
We plan the data model, APIs and integrations behind your platform first, then build them, mainly in TypeScript and Node.js, with Python or Java where a project calls for it.
§01Blueprint first
What we design before any code.
Many rewrites start with decisions nobody made on purpose. We settle these four in writing at the start of a project, and revisit them as the platform grows.
- Decision 01
Data model
The records your business runs on, how they relate, and which rules must always hold. Usually a PostgreSQL schema with constraints the database enforces itself.
- Decision 02
API contracts
Typed endpoints with input checked at the boundary, so bad data is rejected before it reaches the database and the front end knows exactly what to expect.
- Decision 03
Integrations
Payments, shipping, accounting, CRMs. For each one we decide what it owns, what we store, and what happens when it is slow, down or sends the same webhook twice.
- Decision 04
Hosting and delivery
Where the system runs, how changes are tested and deployed, and how environments are kept apart. Containers and CI/CD on Google Cloud are our usual starting point.
Fig. 01 · Layers of a platformOne API in the middle
§02Languages
The right language for each part of the job.
TypeScript is where most of our work lives. Python and Java come in when the problem, or the systems around it, call for them.
Python
Data processing, reporting pipelines and work that leans on Python's data and machine-learning libraries, usually as a separate service the main API calls.
Java
Connecting to established enterprise systems, including older SOAP services, where a mature, strongly typed runtime keeps the integration predictable.
Why typed contracts matter
The contract for each record is written once and shared. The API checks every request against it, and the front end is built against the same types, so the two cannot quietly disagree.
- One definition of each record, used by the API, the database layer and the front end
- Invalid requests rejected with a clear error instead of reaching your data
- Refactors the compiler checks for you, across the whole codebase
order.tsIllustrative example
// One definition of an order, shared by the API and the front end
export const Order = z.object({
id: z.string().uuid(),
customerId: z.string().uuid(),
lines: z.array(OrderLine).min(1),
status: z.enum(["pending", "paid", "shipped"]),
});
export type Order = z.infer<typeof Order>;
// Bad input is rejected here, before it reaches the database
const order = Order.parse(request.body);§03Principles
Built to change without starting over.
The habits that keep a custom system maintainable after launch, whoever works on it next.
One source of truth
Each piece of data has one owner. Other systems read it or receive it; they do not keep their own copy that drifts.
Safe to retry
Webhooks and background jobs are idempotent, so a payment notification that arrives twice does not create two orders.
Tested on every change
Automated checks run in CI before anything reaches a live environment.
Migrations in version control
Database changes are scripted, reviewed and repeatable, never applied by hand.
Decisions written down
Architecture notes explain why the system is shaped the way it is, not only what it does.
Yours to keep
Standard tools, your repositories and your cloud accounts. No proprietary framework to unwind later.
§04Further reading
Where to go from here.
For business owners
Custom business software
Internal tools, portals, quoting and ordering systems built around how you work, explained without the jargon.
See the serviceField studyGreat Lakes Additive
The architecture in Fig. 01 in practice: a WooCommerce store rebuilt as a custom Next.js and Node.js platform.
Read the field studyNext season starts here
Planning a system that has to last?
Tell us what the software needs to do and what it has to connect to. We will sketch the architecture with you and outline a clear plan, even if the first step is small.
- Free, no-obligation consultation
- Reply within one business day
- Led by a principal architect