Eutell

01 · Philosophy

About Eutell

A full-time hire takes three months to become useful. We start on Monday.

Eutell is a fractional CTO practice: two senior engineers with twelve years of production systems behind them and eighteen months working with frontier models daily. You get enterprise-grade engineering at the pace AI now makes possible, without the headcount, the ramp-up, or the risk of one hire being the wrong hire.

Written by AI

Research, code, analysis, and docs

Owned by an engineer

Decisions that are expensive to reverse

Both halves are real work. What divides them is consequence, not volume: the decisions you cannot take back are owned by the engineer who will answer for them.

  • Speed is a by-product

    We did not adopt AI to ship faster. We adopted it to spend our hours on the parts of a system that actually decide whether it holds up.

  • Review is not optional

    Generated code is a draft. It is read, reshaped, and signed off by the engineer who will be answering for it in six months.

  • Small on purpose

    Two people, no bench to keep busy, no layer between you and the person writing the software. You get an answer, not a status update.

02 · Principles

Core engineering principles.

Four positions that decide how a system gets built here. They are not aspirations — each one costs us something, and that is how you know they are real.

  • Architecture

    Boundaries before code

    Schemas, service edges, and data ownership are settled before anything is generated, because those are the decisions traffic makes permanent. AI is very good at filling a shape. It is not accountable for choosing the wrong one.

  • Security

    Access is designed, never inherited

    Authentication, authorisation, and what each role may touch are specified by a person and reviewed by a person. This is the one area where we do not accept a generated answer without reading every line of it.

  • Maintainability

    Written for the next engineer

    The measure of a codebase is how safely someone else can change it a year from now. Consistent patterns, real tests, and documentation that is generated as a side-effect of the work rather than promised after it.

  • Delivery

    Production or it does not count

    Deployments, monitoring, and rollback are part of the build, not a phase after it. A prototype that cannot be operated is not a smaller version of the product — it is a different thing entirely.

03 · Sectors

Experience across industries.

Not a list of markets we would like to serve. Each row is a system we have built and released, and the constraint that made it hard.

  • Hospitality

    Multi-tenant restaurant operations — menus, modifiers, table mapping and role-based workflows across locations, with AI inside the daily routine rather than beside it.

    • Multi-tenant
    • AI
  • Automotive

    Many dealer sites from one codebase, where server-side rendering and page speed are the product, and structured inventory has to stay correct across every tenant.

    • SSR
    • Scale
  • Finance

    Accounting software consolidating dealership data from global sources — turning inconsistent operational exports into figures a finance team can close a month on.

    • Data pipeline
    • Enterprise
  • Trades

    A portfolio builder for blue-collar workers, assembled and published from a phone — proof of skill for people whose work has never had a good place to live online.

    • Web
    • Mobile
  • SaaS & content

    Brand-voice content generation that holds a client's tone instead of flattening it into the same machine register — the difference between usable output and output that gets rewritten.

    • AI
    • SaaS
  • Consumer mobile

    Native iOS work where on-device behaviour, offline handling and backend alignment matter more than the screens — apps that keep working when conditions stop being ideal.

    • iOS
    • Native

04 · Approach

How the work runs

Our technical approach.

Five phases, in order, on every engagement. The label under each one says who owns it — that is the only thing about our process worth memorising.

  • 01

    Design

    Boundaries, schema, and interfaces agreed and written down before generation starts.

    Engineer

  • 02

    Generate

    Agents produce the structure, the wiring, the fixtures and the first pass at coverage.

    AI-led

  • 03

    Review

    Every line read against the design. Security and data access read twice.

    Engineer

  • 04

    Ship

    Deployed through the pipeline that will carry it for the rest of its life.

    Engineer

  • 05

    Operate

    Monitoring, iteration, and an engineer who already knows the system.

    Engineer

05 · Difference

What makes us different.

Six claims, each with the thing that makes it checkable. If we cannot show you the proof, we do not make the claim.

  • One engagement replaces a hire you would have spent a quarter recruiting.

    Recruiting a senior engineer is a quarter of somebody's year, and the wrong one costs you two. An engagement carries neither the lead time nor the risk.

    Proof

    No recruitment, no onboarding, no notice period. Published rates, a scope you can price, and work starting the week you say yes.

  • Our AI writes code you cannot pick out of a review.

    The objection to generated code is fair, and it is about discipline rather than the model. House patterns, conventions that do not bend because a generator found it easier, and a review that reads every line.

    Proof

    The guard rails are the product — a named engineer signs off every release and lives with it afterwards.

  • You talk to the engineer who writes the code.

    No account manager, no delivery lead relaying a question to someone you have never met. The person answering you is the person with commit access.

    Proof

    A team of two. Obie owns architecture and what ships; Priscilla owns scope, timelines and communication.

  • The AI-augmented claim is eighteen months old, not eighteen days.

    We have been building this way since well before it was a line on everyone's website, which is why we can tell you precisely where it works and where it does not.

    Proof

    Eighteen months working with frontier models daily, on production systems, not demos.

  • Two people, enterprise output.

    The interesting number is not how fast we write code. It is how much system two engineers can own without the quality falling over.

    Proof

    Four enterprise systems and a set of internal tools, designed, built and released by the two of us.

  • Our rate is on the website.

    You should be able to work out roughly what something costs before you speak to anyone. Discovery calls that exist only to reveal a price waste both sides' time.

    Proof

    $200/hour, published. An estimator on this site that gives you a figure without a conversation.

06 · Values

Our values.

Four of them, written as things we actually do rather than words we would like associated with us.

  • Say the expensive thing early.

    If the approach you have asked for is going to cost more than it should, you hear that in the first conversation, not in month three when it is our problem too.

  • Own it after it ships.

    The interesting failures happen in production, months later. Accountability that ends at handover is not accountability.

  • No mystery in the estimate.

    Published rates, a scope you can price, and a shared definition of done before anyone writes anything.

  • Leave it better documented than we found it.

    Whether you keep working with us or not, the system should be legible to whoever comes next. That is the job, not a favour.

A useful first conversation

Want to know whether this way of working suits you?

Tell us what production means for your product. We’ll tell you honestly what it takes, and whether we are the right two people for it.