Portfolio #2: Project Acme (Fresh Build)

A project brief is the closest thing to a real FDE engagement you can build without a client. This one gives you the whole thing — the messy data, the creaky API, the stakeholders, the deadline — plus the rubric it will be graded against. The brief is the job; the rubric is the contract.

Why this brief exists

Stage 6 is the Get Hired stage, and its currency is evidence. A hiring manager for a forward deployed role is not buying certificates; they are buying a prediction about how you behave when a client's data is a mess, their API fights back, and their executives want a demo on Friday. Tutorials cannot provide that evidence. A fresh-build engagement brief can — because it forces you to make the same trade-offs a working FDE makes: what to clarify, what to measure, what to harden, what to document, and what to refuse.

This brief is deliberately fresh build, not a guided walkthrough. You are given the engagement the way a real one arrives: incomplete information, competing stakeholders, hard constraints, and a deadline. What you produce is a portfolio artifact that reads like field work — discovery notes, a data contract, a reconciliation report, a connector, a dashboard, a copilot with evals, a runbook. Each artifact answers a question a hiring manager actually asks: can this person turn a drowning client into a live system without breaking the business?

Two rules govern everything below. First, grade outcomes, not completion — the curriculum's milestone-scorecard rule. A pipeline that runs but silently drops 3% of orders is worse than an honest report that says "we can migrate 97% today and here is exactly what the other 3% needs." Second, separate what you observed from what you decided: profile the data before you clean it, measure the API before you trust it, evaluate the copilot before you demo it.

Useful background, if you need a refresher before starting: Discovery: Turning "We're Drowning" Into a Problem Statement, Scoping & Success Metrics: What You'll Refuse to Build, and Designing Systems Under Constraints.

1. The engagement: Acme Corp

Everything in this section is fictional and illustrative — a composite engagement assembled from common patterns, so you can execute it without a real client. Treat it as real while you work: make decisions, write them down, and be ready to defend them.

Who you are

You are a Forward Deployed Engineer at a software company that sells Nimbus, a fictional business-operations platform: dashboards, data pipelines, integrations, and AI assistants, all tenant-isolated per customer. A new customer has signed. You are the engineer sent to get them live.

Who the client is

Acme Corp (fictional) is a mid-size retailer: a few dozen stores plus an online shop, operating for roughly a decade. They are successful in the way that creates the mess — growth outpaced systems. Their ask, in the sales rep's one-liner: "We need one view of our business and an AI assistant that can answer questions from our SOP documents." Your job in week 1 is to turn that sentence into a problem statement you can build against.

What they bring you

Three assets, each a classic FDE headache:

1. A decade of orders trapped in Excel and CSV exports. Not a database — exports, produced by hand, by different people, over ten years. Expect the full catalog of real-world damage: inconsistent date formats (03/04/2019 next to 2019-04-03 next to Apr 3 19), duplicate customers ("Acme Retail Ltd" vs "ACME RETAIL LTD." vs "acme-retail"), missing SKUs on a meaningful share of rows, and shifting column names — the same field called OrderID, order_id, Order No, and id depending on the year and who exported it. Some files are UTF-8, some are not. Some have 12 columns, some have 31.
2. A legacy inventory system behind a creaky REST API. It is the system of record for stock levels and it is not going anywhere — Acme's warehouse runs on it. The API has authentication (an aging token scheme), pagination (inconsistent page sizes, occasional duplicate pages), undocumented rate limits, intermittent 500s, and webhook support that fires unreliably. There is partial documentation, and you should trust it the way you'd trust a stranger's directions: verify everything. Background reading: Legacy Systems, SDK Design & Debugging Someone Else's API, Pagination, Rate Limits & Retries, Auth in the Wild, Webhooks.
3. Stakeholders who need two things live: a dashboard and an AI assistant over their SOP docs. The dashboard must show the business truthfully — orders, revenue, inventory — on data you migrated and integrated yourself. The assistant must answer staff questions from their standard operating procedures: returns, refunds, shipping cutoffs, discount rules. It must cite its sources, and it must not invent policy.

The goal and the deadline

Get Acme live on Nimbus in six weeks without breaking their business. "Live" means: their order history migrated and reconciled, inventory flowing from the legacy API, a dashboard their CFO trusts, an SOP assistant their staff can use, and a handoff package their team (or yours, after you leave) can operate. "Without breaking their business" means the legacy inventory system keeps running untouched throughout — you integrate read-only, cut over in stages, and can roll back.

Stakeholder notes (illustrative)

The following notes are fictional and illustrative — composites of the kinds of things stakeholders actually say. Read them the way you'd read discovery interview notes: every line hides a requirement, a risk, or a trap.

For the discovery technique behind turning notes like these into a buildable problem statement, see Discovery. For deciding what you will not build in six weeks, see Scoping & Success Metrics.

2. The six-week plan

This is the milestone spine. Each milestone has exit criteria — things that must be true, not things you must have attempted. You may compress or reorder weeks, but you may not skip an exit criterion. If a criterion is not met, the milestone is not done, and you say so in your status notes: honesty about a red milestone is itself graded (see the rubric).

3. Deliverables checklist

When the six weeks are over, this is the package on the table. Each item is an artifact a real engagement would leave behind — and each one is something you can show in an interview without violating anyone's confidentiality, because the client is fictional.

Anatomy of three artifacts (worked excerpts)

Abstract checklists don't teach; artifacts do. Below are condensed excerpts of what three of the highest-weight deliverables actually look like. They are illustrative examples in the fictional Acme context — yours will differ in the details, but should match in rigor.

Excerpt 1 — data contract (versioned YAML). Note what it does not do: it never guesses. Ambiguous dates go to quarantine with a rule name, not to a silent default.

# data-contract v0.3 — Acme Corp orders (fictional example)
# Approved by: Dana (CFO), Acme — 2026-10-20 (illustrative)
entities:
  order:
    fields:
      order_id:      {type: string, required: true}
      order_date:    {type: date, required: true, format: ISO-8601}
      customer_key:  {type: string, required: true}   # normalized name + postcode
      sku:           {type: string, required: false}  # missing -> quarantine, not drop
      line_total:    {type: money, required: true, currency: USD}
normalization:
  - dates: all observed formats mapped -> ISO-8601; unparseable -> quarantine(rule=date_unparseable)
  - customers: lowercase, strip punctuation/suffixes -> match key; collisions -> quarantine(rule=customer_collision)
  - columns: per-year alias map (OrderID/order_id/Order No/id -> order_id)
validation:
  reject:    [order_id missing, line_total <= 0, order_date in future]
  quarantine: [date_unparseable, customer_collision, sku missing]
  warn:      [line_total rounding > $0.01 vs source]
quarantine_policy:
  owner: Acme ops (Priya) reviews weekly; unreviewed rows stay quarantined,
         never auto-promoted. Reject-rate tolerance set by Acme, not by us.

Excerpt 2 — reconciliation report (tail). This is the page Dana reads. Every source row is accounted for in exactly one bucket, and revenue ties to the cent.

RECONCILIATION — orders migration, run 2026-11-02 (fictional example)
Source exports scanned ............ 1,284,306 rows (212 files, 2016-2026)
Migrated clean .................... 1,251,882 rows  (97.47%)
Quarantined .......................    28,914 rows  (2.25%)  -> review table, reasons attached
Rejected ..........................     3,510 rows  (0.27%)  -> enumerated in validation report
Accounted for ..................... 1,284,306 rows (100.00%)  -- no silent drops
Revenue, source exports ........... $48,213,904.17
Revenue, migrated ................. $47,092,311.55
Revenue, quarantined (est.) ....... $ 1,118,082.40
Revenue, rejected ................. $     3,510.22
Totals reconcile to the cent ..... YES
Determinism check (re-run diff) .. IDENTICAL

Excerpt 3 — weekly status note (week 4). Notice the honest red milestone, the plan attached to it, and the absence of adjectives doing the work of evidence.

That status note is doing three jobs at once: it reports truthfully (rubric: stakeholder communication), it protects the deadline by re-scoping instead of hoping (constraints), and it asks the customer to own the decision that is theirs (quarantine policy). If you can write that note every Friday for six weeks, you can do this job.

4. Constraints: don't break the business

Constraints are what separate an engagement from a side project. These are non-negotiable; violating one fails the brief no matter how shiny the dashboard is.

Constraint 1: The legacy system is untouchable

The inventory API is the system of record for a working warehouse. Your integration is read-only: no writes, no schema changes, no "quick fixes" to their side. You may not add load that risks the warehouse during peak — Marcus's warning about the holiday rush is a hard boundary. Design the connector accordingly: cache aggressively, sync on a schedule the business approves, back off the moment the API shows stress, and have a documented kill switch. If the API goes down, Acme's warehouse keeps working and your dashboard shows stale-but-labeled data, never silently wrong data.

Constraint 2: The data is guilty until proven innocent

Ten years of hand-made exports will contain contradictions no one remembers creating. Your job is not to "clean the data" as a heroic solo act — it is to make the mess visible and get decisions from the customer. The quarantine policy belongs to Acme: you propose thresholds and consequences, they approve. Every row you reject or quarantine is enumerated in the validation report with a reason. Silent drops are a trust violation — Priya's team will find the one wrong number, and that will be the number they remember.

A concrete trap to plan for: 03/04/2019 is March 4th or April 3rd depending on who typed it. You cannot resolve this by guessing. The data contract must say how ambiguous dates are handled (quarantine? customer ruling? per-file locale evidence?), and the reconciliation report must show the decision was applied consistently. Date handling background: Dates, Timezones & Money.

Constraint 3: The copilot may not invent policy

Sam's fear is the correct fear. An assistant that answers "what is the return policy?" with a confident, plausible, wrong answer is worse than no assistant. So: citations against the retrieved evidence set on every answer, an explicit "I don't find this in the SOPs" behavior, evals that measure groundedness (not just fluency), and guardrails around PII and audit. If the eval numbers are bad, you report them and narrow the scope — you do not ship and hope. Background: Guardrails, Approvals & Audit and Evals & Tracing.

Constraint 4: Six weeks means saying no

You cannot rebuild their warehouse system, unify a decade of master data perfectly, and ship a general-purpose AI platform in six weeks — and pretending otherwise is how engagements die. The out-of-scope list in your discovery memo is a deliverable, not an apology. A good one names the tempting things you refused (real-time sync? full customer-master dedup across all history? multi-language SOPs?) and says what the client gets instead.

5. The rubric: graded on outcomes, not completion

This is the contract. Score yourself — or have a peer score you — against outcomes that can be checked, not effort you put in. Weights sum to 100. For each criterion, "excellent" means the outcome is demonstrated with evidence; "acceptable" means it works but the evidence is thin; "needs work" means a hiring manager would spot the gap in an interview.

How engagements typically fail each row

Read the rubric as a list of the six ways this engagement dies in practice. Each failure below is a composite of mistakes working engineers actually make — check your plan against them:

• Data integrity: the "looks right" migration — spot-checked ten rows, never reconciled totals, and the 2% of dropped rows are discovered by the CFO, not by you. The fix was always the same: a reconciliation report run before anyone asks for it.
• API integration: the happy-path connector — built against the docs, never against the API's actual behavior, so the first duplicate webhook page double-counts inventory in production. The fix: probe first, assume nothing, deduplicate everything.
• Copilot quality: the demo-driven copilot — tuned on the five questions in the demo script, never evaluated on the questions staff actually ask, and the first abstention failure happens in front of a user. The fix: an eval set built from real question distributions before the demo.
• Deployment: the laptop deployment — everything works until the engineer goes on vacation, because secrets, monitoring, and rollback lived in their head. The fix: the runbook test — hand it to a stranger.
• Communication: the green-status fiction — weeks of "on track" followed by a week-6 surprise, which teaches the client that your status notes are marketing. The fix: report the red milestone the week it turns red, with the recovery plan attached.
• Handoff: the "call me" handoff — no runbook, no ownership transfer, and six months later nobody knows why the sync job has a cron entry nobody understands. The fix: write the runbook as if you will never be reachable again.

6. Hints (expand when stuck)

Stuck is part of the brief — a real engagement doesn't come with a solutions manual either. But getting permanently blocked helps no one, so here are nudges. Try for at least an hour before opening one.

7. The reference solution unlocks after the attempt

A fully worked reference solution for Project Acme will appear later as an upcoming end-to-end chapter — the same brief, executed with all artifacts, so you can compare your decisions against a second opinion. It unlocks after your attempt for a reason: reading the solution first converts the engagement into a tutorial, and tutorials are exactly what this brief is the antidote to.

The honest order of operations:

1. Attempt the brief yourself — all six weeks (or a compressed version you declare up front), scored against the rubric above.
2. Write down your score with evidence before looking at anything else.
3. Then read the reference chapter and diff your decisions against it: where did you scope differently, what did the reference measure that you didn't, which of your calls survived contact with a second opinion?

The diff in step 3 is where the learning lives — and it's a superb interview story: "here's what I built, here's how I scored it, and here's what I'd change after seeing a second approach."

Project Acme is the second portfolio brief in the Get Hired stage: a fresh build, executed by you, graded by outcomes. The artifacts it leaves behind — discovery memo, data contract, reconciliation report, connector, evals, runbook — are the evidence a hiring manager is actually buying. Build them like the business depends on them, because in the story of this brief, it does.

When you're ready to talk about this work the way an interviewer will probe it, the Get Hired page is your home base for the stage.