Skip to content

Engineering · what we've built

Judge the engineering, not the adjectives.

We don't publish invented savings figures. Our client work is under NDA — so instead, here are the systems we've built, described honestly and in enough detail to evaluate. Read the architecture and judge the engineering for yourself.

Message us on WhatsApp
  • No client names
  • No invented numbers
  • Human approval where money moves
  • You own the code

Built and running

Real architectures, no client names.

Each entry describes a system we engineered — the operational problem, what we built, and why. Client identities stay confidential; the engineering does not.

Quotation & BOQ automation for a maintenance contractor

Document parsingRate & line-item storeTemplate-driven generationReview & approval gate

Flow

  1. RFQ read
  2. Approved rates
  3. BOQ assembled
  4. Human approval
  5. Sent & logged

The problem

A multi-branch maintenance contractor producing dozens of quotations and bills of quantities each month by hand — re-keying the same rates, scope items, and terms in Word and Excel on every job, with pricing that drifted between estimators.

The system we built

An ingestion step reads the incoming scope or RFQ; a structured store holds approved rates and reusable line items; a generation step assembles the quotation and BOQ from approved templates against current rates; and a human review gate signs off before anything leaves the building. Every output is versioned and traceable back to the source request.

Engineering decisions

Generation is constrained to approved rate tables rather than free-form model output, so numbers cannot hallucinate or drift. The human approval step stays in the loop because pricing carries commercial risk — the system removes the typing, not the judgement.

Cash-custody & delivery verification for an FMCG distributor

Per-delivery confirmation (OTP)Reconciliation engineException reportingAudit log

Flow

  1. Dispatch
  2. OTP handover
  3. Reconcile
  4. Exceptions flagged
  5. Audit log

The problem

A beverage distributor moving cash and stock through a field delivery team, where custody, stock reconciliation, and proof of delivery were tracked on paper and trust — leaving room for leakage and disputes that only surfaced weeks later.

The system we built

A delivery-confirmation flow captures a per-delivery confirmation (OTP / signed handover) at the point of exchange; a reconciliation layer matches dispatched stock against confirmed deliveries and cash collected; and exception reporting flags mismatches for a supervisor the same day. Every handover is logged and attributable to a person and a time.

Engineering decisions

The confirmation step was built to be hard to bypass — a control only works if it can't be skipped. Mismatches surface as exceptions rather than blocking the route, so the field team keeps moving while the office gets visibility.

WhatsApp lead capture & qualification for appointment businesses

WhatsApp Cloud APICalendar bookingCRM / Sheet syncBilingual LLM layer

Flow

  1. Instant reply
  2. Qualify
  3. Book slot
  4. CRM / sheet
  5. Human handoff

The problem

An appointment-based business — clinic, salon, or studio — paying for leads across web forms, Instagram, and portals, then losing them to slow or after-hours replies from a team that can't watch the inbox around the clock.

The system we built

A single WhatsApp entry point answers instantly, runs a qualification script (service, timing, budget, location), books into the calendar, and logs the lead to the CRM or a live sheet — with automatic follow-up on leads that go quiet. English and Arabic handling sits at the model layer, with human handoff on anything the script can't confidently resolve.

Engineering decisions

Instant acknowledgement first, qualification second — speed-to-first-reply is what actually saves a paid lead. The bot escalates to a human rather than guessing when intent is ambiguous, so edge cases don't turn into bad bookings.

How we work

Seriousness you can check.

Three habits that decide whether an AI system survives contact with real operations.

  1. 1Before any proposal

    How we scope

    We map the real workflow before proposing anything — including the exceptions and the manual workarounds people have quietly built. Acceptance criteria are written down and agreed up front, so "done" means the same thing to both sides.

    You get: Written scope + fixed quote

  2. 2During the build

    How we handle failure

    Production LLM systems fail in ways demos never show. We constrain outputs to structured formats, validate against your data, and define what happens on low confidence — escalate to a human, retry, or hold — rather than letting the model improvise on live operations.

    You get: Defined failure modes

  3. 3At go-live and after

    How we hand over

    Every system runs with logging and monitoring so failures surface early, and it's documented and handed to your team to own. No black boxes, no dependency on us to keep the lights on.

    You get: Monitoring + full ownership

Where we stand

A small team, under NDA.

We're a small engineering team. Our client work is under NDA, so we don't trade in anonymous case-study numbers you can't verify.

We show you the architecture instead — the systems above, described in enough detail to judge the engineering directly. In our experience, buyers respect that far more than a wall of invented percentages. If you want to see how we'd approach your problem specifically, tell us what it is.

WhatsApp us