Skip to content

The system underneath the work.

Three layers a request passes through, and two that cut across all of them. What follows is the system the studio builds on, not a list of logos.

No framework is chosen for its own sake. Each one earns its place by making the result faster, more accessible or easier for the next person to maintain.

The shape of the system.

  • Web

    Everything a visitor or an operator actually touches, assembled on the server before it is sent.

  • Backend

    Where a request stops being a page and becomes a decision: validate it, authorise it, carry it out.

  • Data

    Where state lives, and the one place a fact is allowed to be true.

  • AI

    The work that is language-shaped — drafting, triage, summarising, answering — given to a system with a defined input and a defined output.

  • Infrastructure

    Everything the other four need in order to run, stay reachable, and be observed while they do it.

The path a request takes.

Three layers in sequence and two across them. Reading the six steps below is the whole of the architecture — the drawing beside them adds nothing you would miss.

  1. A request arrives

    Served over HTTPS. Pages that can be built ahead of time already exist as files; the rest are rendered when they are asked for.

  2. The web layer renders it

    React components run on the server and assemble the finished page. What reaches the browser is content, not a loading state waiting on a script.

  3. The backend decides

    For anything the page cannot resolve on its own — a write, a login, a call to an outside platform — Node and Express validate the request, check the permission and carry it out.

  4. The data layer answers

    One typed query against the store chosen for that project. The shape it returns is the shape every layer above it already expects.

  5. AI is called, not assumed

    Where the task is language-shaped, the backend calls an agent with a defined input and output. Nothing it produces for an outside audience is sent before a person has seen it.

  6. Infrastructure holds it up

    Deployment, access control, monitoring and the performance budget apply to all of the above at once, rather than to any one of them in particular.

Five layers, and what each one owes the others.

Three of them a request passes through in order. Two of them are not a step at all — one is called, the other holds the rest up.

  1. Web

    Everything a visitor or an operator actually touches, assembled on the server before it is sent.

    Renders the page and, where it needs something it cannot resolve itself, hands a typed request down to the application layer.

    • Server-rendered pages
    • Component and token system
    • Accessible markup and keyboard operation
    • Typed content and route definitions
  2. Backend

    Where a request stops being a page and becomes a decision: validate it, authorise it, carry it out.

    Takes the request from the web layer, checks who is asking and whether they may, then queries the data layer or calls the AI layer — and returns one typed shape either way.

    • Request validation
    • Authentication and authorisation
    • Business rules
    • Integration with outside platforms
  3. Data

    Where state lives, and the one place a fact is allowed to be true.

    Answers the application layer and nothing above it. The record shape is defined once, in types, and shared upward — so a value written in one layer cannot be read as something else in another.

    • Schema and relationships
    • Migrations
    • Backups and restore
    • Structured exports
  4. AI

    The work that is language-shaped — drafting, triage, summarising, answering — given to a system with a defined input and a defined output.

    Not a step in the request path. The application layer calls it deliberately, for a named task, and anything bound for an audience outside the organisation waits for a person first.

    • Drafting and triage
    • Summarisation
    • Answers grounded in your own documents
    • A review step before anything public
    • Logged runs and evaluation
  5. Infrastructure

    Everything the other four need in order to run, stay reachable, and be observed while they do it.

    Wraps the whole path rather than sitting inside it. A change to any layer is deployed, measured and — if it has to be — rolled back by this one.

    • Deployment and rollback
    • Access control and secret handling
    • Monitoring and alerting
    • Performance budgets

A stack is a claim. A release process is evidence.

Anyone can list frameworks. What decides whether they hold is what has to be true before a change is allowed out.

  1. Checked before it ships

    Lint, typecheck, a contrast audit of every semantic colour pair and a production build run on every change. A release is blocked by a machine rather than by a reviewer's attention.

  2. Previewed, then promoted

    Changes go to a preview URL and are read there. The live domain only ever receives something that has already been looked at, and can be rolled back to what it was.

  3. Typed end to end

    One set of types from the data store to the interface. A change that breaks something fails at build time instead of in front of a user.

  4. Access belongs to the client

    Accounts are created in the organisation's name, secrets stay out of the repository, and handover is the default state rather than something arranged at the end.

  5. This site runs on it

    nextneta.online is built on the web layer above — server-rendered Next.js and React in TypeScript, deployed on Vercel — and passes the same four checks before every deploy. It is the one piece of this page you can verify yourself.

What none of this claims.

  • Named tools, not endorsements

    Every name on this page is something we build with. None of it is a certification, a partnership, an accreditation or a vendor relationship, and we have not claimed one.

  • No benchmarks

    There are no uptime percentages, response times or throughput figures here, because we have not published a measurement you could check. When a project has one, it belongs to that project and to the people who can evidence it.

  • Chosen per project, in writing

    The stack is a range, not a mandate. Three databases on this page means the choice is made per engagement — relational where the shape is known and integrity matters, document where it varies — and whichever is chosen is written into that project's scope with the reason.

None of it is the point on its own.

The stack exists to build six things. Tell us which one you need and we will tell you what we would build, what it would take, and what we would leave out.