Updated shortlist, and the teams these five make

The short version: the strongest submission received. Every figure correct but one, and that one is a deliberate refusal he can defend. It survived every test thrown at it, and he tells you himself where his own answer key was wrong.

What it got right

• Fifteen of sixteen figures correct, including both deliberate traps: the supplier email that quietly replaces two hotel rates, and the tour priced per vehicle rather than per person.
• The sixteenth is a refusal, not a mistake. The rate pack says a Johannesburg meet and greet has no matching rate, so rather than borrow the Cape Town price he refused to quote it and raised it as blocking. That reading is arguably stricter than the answer key.
• All seven things a human must resolve were caught, plus six more, split into seven that stop the quote being sent and fourteen to confirm.
• Every figure carries a quote from the source document. All twenty-six were checked against the original PDFs by hand. All twenty-six matched word for word, so anyone can search the source and find the line.
• His output says when a quote is not ready. It emits a plain not-sendable flag with the reason attached. Nobody else built anything like it.
• He catches the chronology trap automatically. The rate pack was compiled two days after the email that overrides it, so ordinary date order points the wrong way. His system spots the contradiction and says so in the review note rather than quietly picking one.
• He works out quantities from the price, not from the printed count. The quotation prints “2 x” conservation levy for a party of five. Rather than a rule about levies, his system notices the printed count disagrees with what the rate implies and flags it. That same logic would catch the equivalent error from a supplier nobody has seen before.

What was tested afterwards

• Trip dates moved forward a year: it correctly refused to reuse expired prices and raised the affected lines.
• A booked service deleted: it disappeared from the total rather than being silently billed.
• A new service added with no matching price: flagged, unpriced, and left out of the total.
• A room renamed so the price no longer matched: kept on the quote, unpriced, and raised for review.
• Two figures deliberately corrupted in his output: his own integrity check caught both.

What to weigh

• No formal test suite. He built a strong integrity checker instead, and it was verified to work, but that is one safety layer where the very best submissions have two.
• Twenty-one review items is a lot for a consultant to work through, even sorted into blocking and confirm.
• Prices with no stated expiry date are never checked for expiry. Narrow, and worth raising with him.
• He spent roughly three hours against a two-hour brief, and says so.

On the walkthrough

He starts the live run at the beginning of the video and returns to it at the end, so the pipeline is genuinely running on screen rather than replayed. Six minutes against a five-minute ask, the closest of anyone. Twice he volunteers something against himself: that his own hand-written answer key was wrong and the AI corrected him, and that early on the model kept returning tidy output that was quietly missing most of the services, which he fixed by forcing it to commit to a count and refusing partial results. He reads from prepared notes and the delivery is imperfect.

What he has built

He is the engineer behind a product used by bail bond agencies in Utah, working as its acting CTO. Someone calls, an AI answers, takes the details, looks up the case, scores the application and produces the paperwork. A person approves it, and only then is a payment link sent.

The part that maps onto your problem

There are around sixteen thousand of these agencies in the US and each has its own forms. His system reads a document it has never seen, works out what each field is for, and places the case information into it. That is the same shape as reading a supplier’s rate sheet you did not design, though it stops short of pulling a price out of one.

The answer that stood out

Asked where a human sits in the chain, he said the system scores and stops. It does not act, because acting on some of those grounds would be illegal. He arrived at approve-before-money-moves through a real constraint rather than a design preference, which is why I believe he would hold that line here.

What the exercise settled

Both of the open questions. He can pull structured figures out of a supplier document under time pressure, and he has a way of checking his own accuracy: he wrote an answer key by hand from your documents first, then had his program grade itself against it. When the two disagreed on one line, he investigated, found his own key was wrong, and changed it rather than the program. That is the habit you want in whoever owns the numbers.

He turned the exercise around the same night it was sent, and he is still available to start with no notice period.

The short version: he found every problem hidden in the documents, his figures reconcile exactly against our answer key, and he reported a fault in his own work that nobody asked about.

What he found

Seven problems were deliberately hidden in those documents. He found all seven, including the one that matters most: a villa the client booked that has no price anywhere. His quote comes to $30,140 and he says plainly that it cannot be sent. Five services have no price at all, and one of them stops the whole thing.

The test that separated him

I changed his source data four ways without telling him: renamed a room type, deleted a service, added one that did not exist, and moved the whole trip forward a year. Each time it did the right thing. Nothing was quietly dropped, nothing was quietly charged, and when the dates moved past the end of the rate sheet it flagged every line rather than reusing last year’s prices.

The moment worth knowing about

One line in the rate sheet is damaged, so the text comes out garbled. His system worked out the right price anyway, then wrote a tidy quotation of a source that does not exist in the document. The AI got the number right and invented the evidence for it.

He found that himself, built a check that detects it, and opened his write-up with it. He is the only person in this search who has reported a fault in their own work.

One line in his video to read in context

He says “actually, my tests are wrong.” What he means is that he wrote his tests first, they exposed gaps, and he ran out of time to close all of them. The suite passes and I ran it. He is pointing at his own published accuracy report, which shows where his system scores badly. It is a disclosure rather than a defect, but it sounds worse than it is.

How he handles being unsure

Every price is sorted into one of five states: confirmed, replaced by a later email, assumed, based on an expired rate, or not found. The label is not a judgement call. It comes from six yes-or-no facts anyone can check. Every figure names the document and the row it came from, so you can verify a number without reading any code.

What he has already built

He leads AI at Yuno, a payments company operating across 80 countries. Payment providers each publish their terms differently. One has a decent website, one sends a PDF, one replies by email. His team built something that reads those sources, turns them into one structured catalogue, and tests each entry against the provider’s real system until it works. Adding a new provider went from about five weeks to hours.

Why that matters here

It is your problem in a different industry, and the important half is the second one: pricing never touches the original documents. It runs against the checked catalogue, offline, with no AI involved. That is the design that stops a made-up number reaching a client.

He also built the system that protects card data at Yuno, which is what allowed the company to be certified to handle payments at all. He is used to work where being wrong has consequences.

The thing he says in his video that stuck with me

“It is really hard to create a prototype and move this to production. In test you can see a PDF with a few tables in one format, and in production you get another PDF with other types of columns and other tables.” That is precisely where you are: something works, and then real supplier documents arrive.

How he comes across

His English is fluent and he is easy enough to follow, but he pauses and restarts more in conversation than in writing, and he tends to explain how something is built before saying what it produced. Both videos open with architecture rather than the result. The substance is all there, it just arrives a minute or two later than you would want.

The one thing to put to him directly

He argues a system like this should eventually run without a person signing off each time, earning that trust through measurement instead. It is a considered position with a real argument behind it, but it is the opposite of approve-before-sending, and it is worth hearing him defend it before you decide.

The short version: she priced a real supplier rate pack correctly, and told us which of her own figures she trusted least before we asked.

What the challenge asked

Everyone received a genuine 26-line supplier rate pack, a real operational quotation and a supplier email correcting some of the prices. The task was to produce costings a system could bill against. It is a compressed version of the job: read messy documents, get the numbers right, and be clear about what is still uncertain.

How the four compared

The moment worth knowing about

The rate pack contained two villas with nearly identical names. Her system took the price of one and applied it to the other, then presented it as a real supplier rate. On the page it looked entirely legitimate.

She caught it herself. Not by reading every line, but because she runs a review process over her own AI output that checks results against the source documents. That process flagged the line, and her final submission marks it unresolved rather than priced.

This is the single most relevant thing in her submission. The danger with automated costing is not the error you can see, it is the plausible-looking figure nobody questions. She has a habit that catches those.

The supplier email

The rate pack was compiled on the 14th. A supplier email correcting some prices was dated the 12th. She identified the conflict, recorded it as an item needing review, and used the email rate because the pack's own terms say correspondence takes precedence. Correct, and she showed her working when asked.

Where she was less strong

She built a check to catch invented prices and had not tested it against one deliberately. She has the right instinct and had not yet closed the loop on proving it works.

The short version: she has done a version of this job before, several times, and it went well. The two open questions are how she works alongside your product engineer and how she handles an early-stage pace.

What she has already built

For a US auto-lending credit union: a system that reads loan application documents and produces credit decisions a human can audit, connected to the client's banking system. 99% accuracy across 1,000 document packages of about 30 pages each, 47 fields per application.

For a European telecom: document classification and extraction across four languages including handwritten forms. Processing time per document dropped from six minutes to one and a half, and daily throughput tripled.

Both are your supplier rate-sheet problem in a different industry, in settings where a wrong figure gets noticed.

Why this matters for AterraAI

The risk with this kind of system is not that it breaks loudly. It is that it drifts. A supplier changes their rate sheet format, the extraction starts misreading one field, and nobody notices for two months because the numbers still look reasonable. Barbara is the candidate who talks about that scenario unprompted and has the habits to catch it.

How she works

She has led 22 customer-facing AI projects from unclear requirements to production, mentored engineers, and made product decisions on incomplete information. In her interview she described keeping written notes of her working sessions and running one AI tool's output past a different one to check it. That is a person who assumes her first answer might be wrong.

The two things to settle

Code review. Part of this role is reviewing your product engineer's work. Her knowledge of that particular language is a few years old and she would use AI tools to help. That is a reasonable approach and it is worth agreeing explicitly how the two of them will handle it, rather than assuming.

Multi-tenancy. Keeping one client's rates invisible to another is central to what you are building. Her answer on this was thinner than the rest of her interview. She understands the concept and has not built it herself.

What she sent afterwards, unprompted

Two days after her call she asked whether a follow-up would be overdoing it, then sent a short document answering the things she had not answered well live: what she would own versus what an engineer would own, why a non-technical founder cannot simply prompt Claude directly, and how a rate change should propagate to a proposal a client has already seen. Nobody asked her for it. She was also candid in it that she has never designed a permissions system from scratch and would use an established pattern rather than invent one.

The short version: every figure right and the clearest presentation of results of anyone, but the step where the AI decides which price applies to which booked item he did by hand rather than automating. He said so in writing before anyone asked.

What it got right

• All sixteen figures correct, including both traps.
• All seven things needing human judgement caught, plus two more nobody was looking for: a trailer charged to a party below the minimum size, and a transfer priced off another city's rate.
• The clearest output in the search for a non-technical reader. It leads with the subtotal it stands behind, keeps the shaky money visibly outside it, and groups what is left by what a person has to do about each one.
• Provenance carries the replaced price too, so a line tells you the story of a rate changing rather than only the winner.
• He built a check on the AI's own explanations. When it answers “why is this number here?” in plain English, a separate piece of code verifies every figure it cites and marks anything invented as unverified.
• Twenty-two tests, all passing, with automated checks running on every change.

What to weigh

• The AI does not do the hardest step. It reads the documents accurately, and a separate calculator works out the totals, but the part in between, deciding which price applies to which booked item and what to multiply it by, he typed in by hand. Several of the flags that look most impressive were written by him rather than found by the system. He listed this first among what he would finish next.
• One real fault. With the trip dates moved forward a year, his system quietly used the old prices and marked them reliable. Asked about it, he had already checked it before the call, but treated it as a feature he had not built rather than a fault. It is the one place his system stops knowing what it does not know.
• No examples of catching his own AI being confidently wrong. Both Kevin and Barbara had them.
• Both the challenge and the video ran over the limits set.

On the walkthrough, and what happened after

His first video ran thirteen minutes against a five-minute ask, and in it he described two checks as automatic when they were the parts he had done by hand. His written notes had it right. Told about both, he re-recorded the same night, came in at four minutes, opened with the result rather than the architecture, and corrected both points himself on camera without being asked to. Both videos are here; the second is the shorter one.

The short version: every number correct, including one our own brief got wrong. His is the only screen that tells a consultant when an entire section of a trip is barely profitable.

What the challenge asked

Rebuild your pricing screen from your reference designs, using a real quotation and real supplier rates. Three situations were included that your designs do not cover, and the brief deliberately did not say what to do about them. That is where judgement shows rather than skill.

His figures against the correct answers

He is the only candidate who shows the trip total to the cent rather than rounding to the nearest dollar, which let us confirm his calculations do not drift as a quote grows. One figure in our own written brief contained a typo, and he calculated it correctly rather than copying our mistake.

The trap the challenge was built around

The data contains one flight discounted below cost to hold the trip under the client's budget. The trip still looks healthy at 12.4% margin, because the loss hides inside the blend. Transport as a section is really running at 1.2%.

His screen is the only one of the three that says so. The row goes fully red, the loss is labelled on the line, a counter at the top jumps straight to it, and the real section margin is shown. His written note explains why: so the loss "can't hide behind a healthy total."

How the three compared

Where he disagreed with your design, and was right

Your reference screen calculates gross profit in a way that counts the travel agent's commission as Aterra's profit. The written brief defines it correctly. Lucas noticed, followed the brief, built a panel that explains the difference line by line, and left a note in the code for whoever comes next:

"Pixel perfect applies to layout, typography, colour and spacing only. Never to reproducing a calculation error."

The code underneath

All three submissions were read line by line. His is the strongest. The pricing formula lives in exactly one place, so a row and a total can never disagree, which is the most common way a pricing screen ends up quoting two different numbers for the same trip. He shipped automated tests and continuous integration, the only candidate who shipped any tests at all.

The short version: the best submission we received for this role, from the cheaper of the two serious candidates. The one thing to test yourself is how easily you follow him.

Where he works now

Senior full-stack at SmartHow, an industrial AI platform, for the past year and a half. The work is close to yours in shape: complex interfaces in the same technology your product uses, backend services and databases behind them, background processing that runs long jobs while the user watches progress, and AI features built on document processing.

Two things there matter for you. He built a cost-tracking and billing reconciliation system for AI spend that holds 0.4% variance between what was recorded and what was invoiced, which is the same discipline your costing engine needs. And he rebuilt a legacy editor into a modular architecture with 85 automated tests, delivering a full platform version in ten days. That is the instinct to improve what exists rather than rewrite it, demonstrated instead of claimed.

Before that, four years at an agency shipping more than 50 production applications, one of which lifted a client's conversion by 200%.

His introduction video is not really an introduction

The second half is an unprompted architecture proposal for AterraAI: where an AI agent should sit, what it must never be allowed to do, and the only two ways a number should be able to enter your system. His summary of it, "the agent reads, classifies and writes prose; it does not compute money and it does not approve anything," is the principle that keeps your figures trustworthy, and he arrived at it before anyone asked him to think about the problem.

He also volunteered his own gaps without being asked. He has never used two of the specific tools in your stack, though he has built the mechanisms underneath both.

What to weigh

His spoken English is fluent, strongly accented and takes real effort to follow. His written reasoning is the best of anyone we screened, so the gap between how he reads and how he sounds is unusually wide. Much of this work happens in writing, which softens it. You would still be speaking to him most weeks, and this is the one thing about him that only you can judge.

The short version: the best-looking and best-explained screen of the three, with two gaps that separate it from Lucas.

His figures against the correct answers

How the three compared

The budget warning

His is the best written of the three. It names your actual clients, quantifies the overage and offers three specific fixes. It then stops the consultant from continuing. One of his three suggested fixes is to raise the agreed budget, and that is not possible anywhere in what he built.

Our view is that the software should warn loudly and let your consultant decide, because sometimes going over is deliberate. This is a design opinion rather than a mistake, and it is worth hearing his reasoning.

What he found that we did not plant

Two hotel rooms booked for the same nights, for two travellers. It was not in our answer key and nobody else noticed. He built a warning for it and used it to give the consultant a way to resolve the unpriced service.

The section margins

Worth being precise, because this is his only real gap. His pricing engine calculates the per-section figures correctly, and the code even notes that a simple average of the markups "would lie." He computes them and never displays them. It is a presentation gap rather than a misunderstanding, and a short piece of work to fix.

The code underneath

Read line by line, and clean. The pricing formula lives in one place, and nothing in the interface recalculates money independently, so a row and a total cannot disagree. The auto-save handling is the most carefully built part of his submission, covering rapid edits, failed saves, retries and network interruptions, none of which was asked for. He shipped no automated tests.

The short version: a genuine alternative. If design quality and ease of communication matter more to you than $2,600 a month, he is the pick.

Where he works now

Senior front-end engineer at Bucksense since late 2023, and before that full-stack at Veckta, an early-stage startup where he worked directly with one of the founders from the beginning. Concrete results at both, and both on his CV: he reduced a page payload from around 19MB to 500KB, cutting worst-case load times from 30 seconds to 5, and built a caching layer that reduced search infrastructure costs by roughly 66%.

Why the travel experience matters

He builds the Abercrombie & Kent website, so itineraries, pricing, availability and how that information has to come together are familiar ground rather than something he would learn on your time. At Veckta he built an interactive modelling tool where changing an input immediately showed the financial impact, which is structurally the same problem as your pricing screen.

The design question

This is where he beats Lucas. His warning states are visually differentiated instead of uniform, his hierarchy is stronger, his contrast is better judged, and his screen sits closest to your existing product. He also shipped a mobile layout nobody asked for. For a founder with strong visual taste and no designer, that is not a small thing.

Nine years before software

He ran his own electrical engineering practice for nine years before switching careers. It shows in how he explains technical decisions. He is the clearest of the three and the easiest to follow.

Terms

He can start now, and asks for a two-week trial before deciding whether to leave his current role. We would suggest taking him up on it. It is a bounded commitment that answers more than an interview does.