Engineering practice, not a product catalogue
Northwind Cloud Systems designs and builds the software a business actually runs on — internal systems, customer platforms, cloud infrastructure, and the data that has to move between them. Then we hand it over in a state someone else can operate.
01Thesis
A system can pass every test on the day it ships and still become unusable: the person who understood it leaves, the deployment only works from one laptop, the vendor account sits in someone's personal name, and the data model quietly stops matching the business.
Position
Northwind exists to close that gap. The work is not only the application — it is the environment it runs in, the pipeline that deploys it, the records it holds, the person who will own it next, and the documentation that makes all of this recoverable.
That is why every engagement here ends with a handover pack rather than a demo. If a system cannot be transferred, it is not finished.
Build for the person who inherits it.Working rule — Northwind Cloud Systems
02Capability
Each track can be commissioned on its own. Most engagements combine two: a platform that needs infrastructure, or a data product that needs an interface.
01
Web applications, internal operating systems, multi-tenant products, administrative back ends and the billing, permission and audit layers around them.
Data model and domain rules, roles and permissions, workflow and exception handling, migration of existing records, admin surfaces, release process.
02
Provisioning, network and access boundaries, containerised or serverless deployment, backup and restore, cost visibility, staged environments.
Infrastructure defined in code rather than console clicks, a preview environment per change, one-command deploy, alerting that names a real person.
03
Ingestion from operational systems, warehouse or lake layout, scheduled transformation, reporting models, retrieval and model-backed features.
A defined source of truth, tested transformations, documented metric definitions, and AI features with a stated failure mode rather than a demo.
04
Connecting systems that already exist: ERP, CRM, accounting, payment, messaging and logistics APIs, plus the support agreement that keeps them running.
Contract-level integration notes, retry and reconciliation behaviour, error queues someone can read, and a named route for support.
03Engagement
No stage is a black box. Every one produces something written that a non-engineer can review and disagree with, before the next stage starts.
STAGE 01
What decision or task the system has to support, who performs it today, and what would count as working.
Out: one-page scope, named assumptions, open questions.
STAGE 02
Entities, states and permissions — the part that is expensive to change later, agreed in words before code.
Out: domain model, role matrix, data-flow sketch.
STAGE 03
Working increments in a preview environment, reviewed by the people who will use them, not by a slide deck.
Out: reviewable increments, decision log, test notes.
STAGE 04
Migration of real records, access cut-over, rollback path tested, monitoring pointed at a person who answers.
Out: release record, rollback steps, access list.
STAGE 05
Either a support agreement, or a handover that leaves your team able to run it without us.
Out: runbook, ownership register, support route.
Read this
before stage 01
Discovery is a paid, bounded piece of work in its own right. It can conclude that the system you asked for is not the one you need — or that a configuration of tools you already pay for will do. That answer is a valid outcome and it is written down like any other.
04Architecture
A representative shape, not a fixed product. Interfaces, services, data and foundation are separated so each can be replaced without rewriting the others.
InterfacesWho touches the system
ServicesWhat the system enforces
DataWhat has to stay true
FoundationWhat keeps it recoverable
Each layer has an owner and an exit. That is the difference between an architecture and a diagram.
05Handover
A project is not complete when the last screen renders. This is the ledger we work against, and the one we will show you at the end.
| Item | What it contains | Format | Held by |
|---|---|---|---|
| Source code | Full history, not a zip of the final state; branch protection and review rules documented. | Your repository | You |
| Infrastructure | Cloud resources defined in code, with the account hierarchy and access matrix written down. | Repository + access register | You |
| Deployment | One documented path from commit to production, including the rollback step. | Pipeline + runbook | You |
| Data | Schema, migration history, retention rule, and a restore that has been tested once. | Schema notes + restore record | You |
| Decisions | Why the model, vendor or approach was chosen — including the options rejected. | Decision log | You |
| Access | Every third-party account, who owns it, and what happens when someone leaves. | Ownership register | You |
| Support | Either a named support route with your team trained, or a written agreement with us. | Runbook or contract | Agreed per project |
06Rules
Rule 01
A number produced before the entities and permissions are understood is a guess with a date attached. We model first, then price the work in slices you can stop between.
Rule 02
Anything shown runs from the same pipeline as production. If a prototype cannot be released, it is a sketch, and it is labelled as one.
Rule 03
Cloud, domain, repository and vendor accounts are created in your organisation from day one. We work inside your boundary, not next to it.
Rule 04
Every external service, licence and manual step is listed with its cost and its replacement path. A system you cannot leave is not a service, it is a trap.
07Company
Northwind Cloud Systems INC was incorporated in California on 29 September 2026, with its principal office in Monterey Park. It is led by its founder, who is also the officer of record. There is no partner network, no reseller tier and no badge wall on this site, because those would describe a company we are not.
What that means in practice: you talk to the person who does the work, scope is agreed in writing, and the first deliverable is a document rather than an invoice.
08Questions
A written scope of one or two pages: the task, the people who perform it, the records involved, the systems it must talk to, and the assumptions we would be making. That document is the first paid deliverable and it is yours to keep whether or not the project continues.
Both. Inherited systems are assessed the same way: what runs today, what deploys it, what would break first, and what can be replaced in slices. Replacing everything at once is rarely the cheapest route and we will say so.
As software with a failure mode. That means a defined input, a stated accuracy expectation, a human review step where the consequence of error matters, a record of what the model was and when it changed, and an off switch. We will not present a language model as an authority it is not.
Yes, after a short assessment: repository and infrastructure review, a release from a clean environment, and a list of what is undocumented. The output is a realistic picture of the cost to continue, not a rescue pitch.
The company's principal office is 111 Elizabeth Ave, Monterey Park, California. Work is delivered remotely by default; on-site attendance is agreed per engagement and priced separately. The office is not a walk-in shop.
Start with the problem, not the stack
Send the task, the systems involved and the deadline you are working to. If we are not the right fit, we will say that in the first reply.
111 Elizabeth Ave · 626-563-3835