How I work

Systems, not demos — and the method that keeps that true.

Most data projects do not fail on technology. They fail because the definition was never agreed, the baseline was never measured, or the thing that got built could not be maintained by anyone except the person who built it. This is how EthanCorp engagements are run to avoid exactly that.

How an EthanCorp engagement runs Five stages: a free scoping call, a paid discovery producing a written assessment, a narrow version one delivered to real users, measurement against the baseline captured during discovery, then handover with runbooks — or an ongoing retainer if you want one. 1 · Scoping call 30 min · free 2 · Discovery Written assessment 3 · Build v1 Narrow and real 4 · Measure Against the baseline 5 · Hand over Runbooks Stated before stage 3, not after The baseline measurement · the constraints I expect to hit · what it costs to run · what happens when it fails · who maintains it after handover
Five stages. The constraints and the running cost are stated before stage 3 — while you can still change your mind cheaply.

The engagement

What actually happens, stage by stage.

No stage is ceremonial. Each one produces something you keep, and each one is a point at which you can stop.

01

Scoping call — 30 minutes, free

You describe the symptom. I ask what has already been tried, who owns the systems involved, and what decision the missing data is blocking. If EthanCorp is not the right fit, you find out here rather than three weeks in.

You end up with: A straight answer on fit, and a rough shape for the work.

02

Discovery — paid, written, yours to keep

Source profiling, an honest read of the current state, and a measured baseline for whatever the engagement is meant to improve. The baseline matters: without it, every later claim about improvement is a story rather than a number.

You end up with: A written assessment with the target architecture, the risks, the constraints and a scoped proposal. It stands on its own even if you stop here.

03

Build v1 — narrow, real, in front of users

One domain, one workflow, one reporting area — built properly rather than broadly. Tested transformations, version control, failure alerting that names the failing step, and no dependency on undocumented knowledge in my head.

You end up with: A working system real users are using, not a prototype waiting for phase two.

04

Measure against the baseline

The same measurement taken in discovery, taken again. If the number did not move, that gets reported as plainly as if it had. An AI workflow additionally reports its acceptance rate under human review — the only honest way to describe how well it works.

You end up with: A before-and-after you can put in front of your own stakeholders.

05

Hand over — or continue, deliberately

Runbooks, architecture notes, credentials handled properly, and a walkthrough with whoever owns it next. If an ongoing contract makes sense, it is because the work is genuinely continuing — not because the system cannot survive without me.

You end up with: Your team owning a maintainable system. That is the success condition.

Operating principles

Five rules that decide what gets built — and what gets refused.

Published because they are the reason some requests get narrowed or pushed back on, and it is fairer that you know that before we start.

Systems, not demos

Anything shipped should still be running, and still be maintainable, twelve months later. A demo that impresses a steering committee and then rots is a cost, not a delivery.

Foundations before front-ends

Data schemas, state tracking, clean contracts and written procedures come before the dashboard skin. A beautiful report on an ungoverned model is a faster way to be confidently wrong.

Automate the repetitive; preserve the human judgement

Automation removes the copy-paste, never the decision. Human-in-the-loop is a design feature, not an admission that the model is not good enough yet.

Ship v1, measure, iterate

An over-engineered master plan that never goes live has delivered nothing. I would rather put a narrow, working v1 in front of real users and let their behaviour decide what v2 contains.

Radical transparency about cost and failure

Token budgets, API rate limits, latency, schema drift, the failure point you will hit in week three — said up front. Buyers who were warned stay; buyers who were sold magic churn.

Transparency

The part most proposals leave out.

Buyers who were warned about a constraint stay. Buyers who were sold a frictionless outcome leave the moment it turns out not to be frictionless.

What I will tell you before you commit

  • Where I think this project is most likely to fail, and at roughly which week
  • What it costs to run after handover — including token spend and API rate limits for anything AI-assisted
  • Which parts of your estate I have not worked with before
  • When a cheaper or simpler approach would get you most of the result

What I will push back on

  • A dashboard commissioned before anyone agrees what the metric means
  • Automating a process that should be removed rather than accelerated
  • An AI step where a rule would be cheaper, faster and auditable
  • A scope that cannot be handed over to your team afterwards

Working with AI

Where the model is allowed to decide, and where it is not.

AI is applied to work that is repetitive, high-volume and measurable — document handling, classification, retrieval, drafting. It is not applied to the judgement the organisation has to stand behind.

In practice that means three rules. Retrieval is grounded in your own curated material, so answers can be traced to a source rather than to the model's general memory. Every generated output passes a human gate before it is released, and the accept/reject outcome is logged so the acceptance rate is a measured number rather than a claim. And where a deterministic rule would do the job, the rule wins — it is cheaper, faster, testable and explainable.

Said plainly

An AI workflow that nobody reviews is not an efficiency gain, it is an unmeasured risk transfer. If a workflow genuinely cannot tolerate a review step, that is a strong signal it should be built with rules rather than a model.

Want to see whether this fits your situation?

A scoping call is 30 minutes and costs nothing. You will get a straight answer on fit — including if the answer is that you do not need this.

Discuss a project See the services
Response time
Within two business days
Based in
Ho Chi Minh City, Vietnam — working across Asia and remote