AJENTX

Software for startups and growing businesses

Quality software, built in a fraction of the time.

We build systems that are robust and easy to read, test and extend. The speed comes from AI. The quality comes from what it is given to work to, and from the people who check what comes back.

TicketExample

As a customer, I want an account that knows who I am, so that my details and settings follow me.

Feature: User Service

Scenario: First sign-in creates a profile

Given a new person signs in through the identity provider

When the service receives their sign-in

Then a profile is created with their name and email

Scenario: A customer updates their details

Given an existing profile

When they change their phone number

Then the new number is saved and confirmed

Scenario: A customer closes their account

Given an existing profile

When they ask to close it

Then their personal data is removed

One story, one service. Written from the intent agreed in requirements, checked by three amigos before it runs, and run as Cucumber tests.

Fast and good

Fast used to mean you paid for it later.

That trade-off goes away when the work before the build is done properly. Here is where each half comes from.

Where the speed comes from

  • Models write the code and agents work the tickets, end to end.
  • A feature is often a whole new service, so each release does more.
  • Generic problems such as identity and email are bought, not rebuilt.
  • A small team, with no hand-offs to wait on.

Where the quality comes from

  • Requirements, architecture and coding standards are settled before any code exists.
  • Every ticket is written from that intent as Given/When/Then scenarios, and checked by three amigos before it runs.
  • Cucumber tests check each slice through the UI. Integration tests check every service endpoint.
  • Telemetry covers every customer journey from start to end.
  • A person holds the codebase to the agreed architecture, principles and practices.

How a build runs

The same order, every time.

Most of the decisions that make a system cheap or expensive to own are made before the first line of code. So that is where the work starts.

  1. 01

    Requirements and intent

    A set period to pin down what the business does, what the product has to do for it, and what it doesn't need yet. The intent for the build comes out of it.

  2. 02

    Build or buy

    Domain-driven design splits the problem. The core that makes you different and the parts that support it get built. Generic problems such as identity are bought.

  3. 03

    Architecture and standards

    Usually small services, each owning its own data. The principles and practices the code must follow are written down.

  4. 04

    Pipeline

    Build once, deploy many. Each service deploys on its own, with its infrastructure, so one change doesn't hold up or put the rest at risk.

  5. 05

    Tickets

    Written from the intent as user stories with Given/When/Then scenarios. A three amigos session is the final check before each one runs.

  6. 06

    Build

    One model manages the work and owns the tests. Another writes the code against them. Agents do the rest. A person checks the codebase keeps to the agreed architecture and standards.

  7. 07

    Check

    Each vertical slice is built with its UI. The scenarios run as Cucumber tests through it, and integration tests cover every service endpoint, all automated rather than run by hand.

  8. 08

    Live, and kept live

    Done means live. Problems found by telemetry are fixed forward: a ticket is raised, approved by a person and built.

Services

We build it, then we look after it.

The build

From requirements to a live system

A system designed around how your business works, built with AI to a written standard and delivered through to production.

  • Requirements, build-or-buy decisions and architecture
  • The pipeline, infrastructure and telemetry
  • The build itself, ticket by ticket, through to live

Quoted to deliver, with continuing support.

Afterwards

Fractional CTO

Once the system is live, it still needs someone holding it to that standard and planning what comes next.

  • Roadmap and priorities
  • The team the product actually needs
  • The platform it runs on
  • The IT budget

Monthly retainer, a few days a month.

The team you need

Smaller than most plans assume.

It depends on the project, but a startup's first platform rarely needs more than this. The money a smaller team saves is better spent getting the product in front of customers.

1 to 2

Developers

Who also own how their code gets to production and runs there.

1

Tester

Who owns acceptance and automates the checks instead of running them by hand.

Possibly 1

Product

When the business needs someone dedicated to deciding what comes next.

Built this way

Bricks N Mortar

A property analytics platform that works out the most an investor should pay for a property, based on the cost of the deal rather than the asking price. A vision model reads the listing photos, and the analysis is available to AI assistants through MCP servers as well as the web app.

It runs as a set of services on Azure, each deploying on its own, with the build following the same process described above.

.NETAzureBicepGitHub ActionsTypeScriptReactMCPAuth0

bricksnmortar.co.uk

Earlier work, as lead or principal engineer

  • Loans APIs for a regulated UK lender, on .NET and Kubernetes
  • A government-data ingestion platform on Azure Functions and Service Bus
  • Checkout and identity for a high-traffic e-commerce business
  • A new engineering department, stood up and delivering

About

Andrew Dobson

Owner and principal consultant

Ajentx is led by Andrew Dobson, a software engineer with twenty-five years of commercial delivery behind him, much of it as a lead or principal engineer brought in to set up teams and the way they work.

Everything he brings to a build with AI comes from doing the work by hand first: where a service boundary should go, which test will break when the code changes, what a requirement has left out. That judgement is what the models are held to.

.NET and Azure by background, with the language and framework chosen for the job. Based in Lancashire and working with clients across the UK.

Contact

Tell us what you're building.

A first conversation is about your business and what the product has to do for it. You'll get a straight answer on what it would take.

Andrew on LinkedIn