Skip to main content
Allways

Product engineering, end to end.

We design, build, secure and run B2B software. Eight disciplines under one technical standard, and one named person accountable for your project from start to finish.

HARD FACTS

Hard facts

We work from
Fully remote, worldwide
Agreements
Terms of engagement, non-disclosure agreement and data processing agreement, all available before the first invoice
Handover
Repository in your own organisation, technical documentation and a guided handover
Response
First reply within 24 business hours by email · 30 minutes with engineering on the first call

Who we are

Senior people, no layers in between.

You talk to the person who writes your code, from the first call to the last deploy. Every project has one named technical owner, a repository in your own organisation from the first commit and a direct channel, with the response time written into the contract. What you get: full context in every answer, with nothing lost in translation. book 30 minutes.

We would rather our code did the talking than our egos.

WHAT WE DO

Eight disciplines. One standard.

This is what we run end to end, without subcontracting the technical judgement. Every discipline comes with its own proof, and the proof is our own material: this site, our repository or our tools. We still do not show client work, because the contracts forbid it and because we would not show yours either.

Product and architecture

  1. Product and systems architecture

    • Domain modelling and explicit boundaries between services
    • Decisions recorded in versioned decision documents inside the repository
    • Data schema design, indexes and a migration strategy
    • Per-route technical budgets agreed before any code is written
    • A twelve-month evolution plan with the breaking points already identified

    Verifiable we show you the decision documents of this site, with the options we ruled out and the measurement that ruled them out.

  2. Product and interface design

    • User journeys with empty, error and loading states all defined
    • A design system with components, tokens and composition rules
    • Documented type hierarchy and spacing scale
    • A clickable prototype before the first line of production code

    Verifiable the token system of this site and the contrast of this page measured node by node, with the tool that calculates it in front of you.

Build

  1. High-performance frontend

    • Next.js and React with strict TypeScript and server rendering
    • A JavaScript budget per route and a regression check on every code review
    • Core web vitals as acceptance criteria, measured in the field and in the lab
    • A token-based design system, not loose stylesheets per page
    • Animation through transform and opacity, with real respect for reduced-motion

    Verifiable measure this very page with PageSpeed from your own phone. You do not have to take our word for anything.

  2. Process automation

    • A map of the current process with the real time each step takes, before automating anything
    • Integration between existing systems through their interfaces, without replacing what works
    • Explicit handling of errors, retries and the cases that need a person
    • An auditable log of every run, with who and when
    • The before and after measured in hours, not in impressions

    Verifiable the automatic guardrail of this repository, with what it blocks and why, and the dated evidence it leaves every time it runs.

Run

  1. Cloud, operations and reliability

    • Infrastructure declared as code, reproducible from scratch
    • Continuous deployment with a preview per branch and one-step rollback
    • Observability with traces, metrics and correlated logs
    • Alerts based on user symptoms, not on processor usage
    • A recovery plan with written recovery time and recovery point objectives

    Verifiable during the call we roll back a deployment of this site, timed, and you watch how long it takes.

  2. Application security

    • Threat modelling at the start of the project, not at the end
    • Secrets managed outside the repository, with documented rotation
    • Dependencies audited continuously, with an update policy
    • Authentication and authorisation tested against privilege escalation
    • Headers, content policy and form protection verified

    Verifiable the dependency audit of this repository exactly as it comes out today, with what is open and what we are going to do about each item.

  3. Handover, documentation and exit

    • Repository in your own organisation from the first commit
    • Runnable instructions: from a clean machine to a working environment, without asking
    • A runbook with the procedures for the most likely failures
    • A recorded handover session and a window of support afterwards

    Verifiable we hand you the start-up instructions of one of our repositories and you run them on your own machine. If a step is missing, that is the defect we take away to fix.

Quality guarantees

  1. Accessibility

    • WCAG 2.2 level AA compliance as an acceptance criterion
    • Full keyboard navigation, with visible focus and a logical order
    • Screen-reader verification on the critical flows
    • Contrast measured, not estimated, in every state of every component
    • System preferences for motion and transparency respected

    Verifiable go through this entire page with the keyboard and without touching the mouse. Then we hand you the verification report for this site, with what it passes and what it does not.

MANIFESTO

The Allways Way

Nine principles. Each with its cost.

A principle that never forces you to turn work down is not a principle, it is advertising. These nine cost us projects, hours and sometimes the quick answer. We hold them anyway.

  1. Code that ages well

    We pick the boring and proven over the new and shiny, because the real cost of a system is not building it but maintaining it for three years.

    What we give up We give up the spectacular demo that falls over the moment the team changes.

  2. Your repository from the first commit

    The repository is created in your name when the project starts, and the exploitation rights to the software are assigned to you exclusively as it is written. At the end we hand over access, documentation and a guided transition.

    What we give up We give up technical lock-in as a retention tactic: if you want to leave, you leave without asking us and without waiting until it suits us.

    Where you can check it read the ownership clause

  3. No layers between you and the code

    You always talk to whoever builds it. What we agree goes in writing, and so does what changes, with its impact on cost, deadline and scope before you decide.

    What we give up We give up the comfort of an account manager who softens the bad news: the bad news comes from us, in writing, inside the service window we work in.

    Where you can check it read the revisions clause

  4. Anything repetitive gets automated

    If a task is done the same way three times, we automate it before doing it a fourth, and human judgement stays where it genuinely belongs.

    What we give up We give up the comfortable support work that lives off manual tasks: every process we automate cuts the overflow hours we could bill you later.

    Where you can check it read the support clause

  5. AI amplifies, it does not sign

    We use our own tools to speed up the mechanical work. Whatever reaches your repository is reviewed and approved by a person.

    What we give up We give up the speed of generating blind: every change comes in through a review signed with a first and last name in the repository history, and you audit that history yourself.

  6. We measure before we opine

    Before optimising we measure, and we hand you the starting number next to the finishing one, with the tool, the route and the percentile it was taken at.

    What we give up We give up the quick opinion over coffee: without a measurement it is a hypothesis and we treat it as one, even when the hypothesis is ours.

  7. Security inside the budget, not after it

    Threat modelling, secret management and audited dependencies are in the original budget and inside the original deadline, not in a later phase quoted separately.

    What we give up We give up winning on price against an offer that leaves this work out. If you compare two quotes and ours is dearer, check whether the other one has this line.

  8. Accessible or it is not finished

    Measured contrast, visible focus, keyboard navigation and screen-reader verification are acceptance criteria, written into the scope annex like any other requirement.

    What we give up We give up signing off a screen that is already approved and fails verification: it goes back to be fixed, and we pay for that rework ourselves.

  9. We would rather say no

    If the deadline, the budget or the problem do not add up, we tell you on the first call, before a proposal exists, and if we know someone who can do it, we tell you that too.

    What we give up We give up billing projects we know will go badly: the work we take on is the work we can defend with the delivery guarantee attached.

If you want your project built by the people who will maintain it, let's talk.

METHOD

How we work

We work without layers and with deliberate focus. When the person deciding is the person building, a change of direction lands the same week instead of travelling through three meetings, and nobody has to translate what somebody else said. Your project does not share a calendar with another project: the first payment reserves a calendar window in your name, and that is written into the terms of engagement, not into this page.

What that model demands of us is more discipline, not less. Everything we know about your system lives in your repository and not in our heads: recorded decisions, an environment reproducible from scratch and a runbook. The technical owner has a first and last name, and their context is not theirs, it is yours, so somebody else can pick it up without doing archaeology. If we stopped existing tomorrow, your team starts the project on its own. That is the standard we measure ourselves against.

We automate everything that can be automated, our own work included. The mechanical part is run by in-house tools that we build and maintain. Whatever reaches your repository is reviewed and approved by a person, and that person can explain it to you. The same code produces the same result, and that is checked on every test run.

Bring the problem. You leave with a technical read on it.

Thirty minutes with the person who will design the solution. No sales deck and no paid discovery. You leave with our read on your problem, the risks we can see and a range of effort, whether we end up working together or not.