The Lintel Case

Why this page exists

Across this guide you design one system, for one company, for ten modules. That company is Lintel.

Lintel is invented, but its facts are fixed. Every topic draws on the numbers, people and constraints on this page and none of them will quietly change later. When you work a workbook exercise, this is where you look things up.

Read it once now. Come back to it whenever a topic mentions a name or a number you don’t recognise.

If a topic ever needs a detail that isn’t here, it will say so explicitly — “assume for this exercise that…” — rather than inventing a new fact. That rule matters: it’s the only thing stopping Module 8 from contradicting Module 2.

The company

Lintel sells field-service management software to other businesses. Their customers are mid-sized construction and facilities firms — companies with vans, tools, and technicians who go to sites. Lintel’s product handles the scheduling, the dispatching, and the work orders.

Founded	2016
Annual recurring revenue	$48M, growing 22% a year
Employees	320, of which about 140 are engineers
Customers	~1,800 companies
Daily users	~95,000 field technicians
Hosting	AWS, primary in eu-central-1, secondary in us-east-1

That size matters more than it looks. At 140 engineers a company is past the point where everyone knows what everyone else is building, but well short of having formal processes to compensate. This is the size at which companies start colliding with themselves — and the size at which they hire their first architect.

The technology today

A Ruby on Rails monolith, written in 2016 and still running most of the business. Around twenty newer Go services sit alongside it. PostgreSQL is the primary database, currently about 4 TB. Redis and Kafka are in the stack.

Lintel is two years into a strangler-fig migration — the gradual approach where you route slices of traffic away from an old system to new ones until the old system is empty rather than replacing it in one move. About 35% of traffic now reaches the new services.

One fact shapes almost every decision you will make:

There is no spare engineering capacity. The migration consumes it.

Any proposal that quietly assumes free engineering time is not a proposal. It’s a wish.

The support problem

Support agents	45, across three time zones
Tool	Zendesk
Volume	~12,000 tickets per month
Cost	$6.40 per ticket
Answerable from existing docs	38%

That 38% is the finding that started everything. An internal audit concluded that nearly four in ten tickets are “how do I…” questions the documentation already answers. Customers ask anyway, and a human answers anyway.

What they want to build

An AI-assisted support platform, with three parts:

• Retrieval over the product documentation and historical tickets, so answers come from what Lintel actually knows.
• An agent that can act — reschedule a job, issue a credit, reset a device. Not just answer questions: change things in the real system.
• Handoff to humans, cleanly, when the agent shouldn’t or can’t continue.

That middle part is where the difficulty lives. An assistant that answers questions wrongly wastes someone’s time. An assistant that issues credits wrongly costs money.

Why they want it

Four drivers, and they are not equally weighted:

Driver	Target
Cost per ticket	$6.40 → $3.00
First-response time	Reduce
Customer satisfaction	Hold or improve
New revenue	Ship a paid “Lintel Copilot” tier within two quarters

The last one is a strategic bet, not a cost saving, and it comes with a deadline someone has already promised externally.

What constrains it

• GDPR and EU data residency.
• SOC 2 Type II compliance.
• Several enterprise contracts forbid customer data leaving its region at all. Not “prefer” — forbid.
• Tickets contain personal data: names, site addresses, phone numbers, and occasionally payment references.

What happened in 2023

In 2023 Lintel shipped a machine-learning feature for “smart routing” — automatically assigning jobs to technicians. It worked at launch. Over the following months it degraded. Eventually it was switched off, quietly, without an announcement.

Nobody brings it up in meetings. Everybody remembers.

You will not find this in any document. You will find it in how people react when you propose something that sounds similar.

Your position

You are Lintel’s first Solution Architect, four weeks into the job.

There is no architecture board. No practice of recording decisions. No mandate describing what you decide and what you don’t. No formal authority over any team.

This is not an oversight in the scenario — it’s the realistic case. Architects are usually hired into this situation rather than into a functioning practice, and much of the skill is building the practice while doing the work. If the exercise handed you authority, the organisational modules later in the guide would teach you nothing.

The people

Seven people determine whether this initiative succeeds. Learn their names — later modules assume you know them.

Person	Role	What they want	What they fear
Maya Ortiz	VP Customer Support	Your sponsor. Relief for her team, faster responses	Her agents reading this as layoffs
Dev Raghunathan	CFO	Approved $1.2M a year. Wants defensible numbers	Open-ended, uncapped spending
Tomas Beck	VP Engineering	Owns all 140 engineers	Another initiative competing with the migration
Priya Shah	Head of Product	The paid Copilot tier, within two quarters	Missing the revenue commitment
Lena Fischer	Head of Security & Compliance	Can block you outright. Personal data, residency, SOC 2	A breach with her name on it
Ivan Petrov	Principal Engineer, owns the monolith	No formal veto, but has one anyway. Eight years here, widely respected	A repeat of 2023
Grace Adeyemi	Support Team Lead	Speaks for the 45 agents	Tooling imposed on her team without asking them

Two of these people can stop the project. Only one of them has it in their job title.

graph TD
  subgraph Money["Holds the budget"]
    DEV[Dev Raghunathan<br/>CFO]
  end
  subgraph Sponsors["Wants it to happen"]
    MAYA[Maya Ortiz<br/>VP Support]
    PRIYA[Priya Shah<br/>Product]
  end
  subgraph Blocks["Can stop it"]
    LENA[Lena Fischer<br/>Security — formal block]
    IVAN[Ivan Petrov<br/>Principal Eng — informal veto]
  end
  subgraph Capacity["Owns the people"]
    TOMAS[Tomas Beck<br/>VP Engineering]
  end
  GRACE[Grace Adeyemi<br/>Support Lead<br/>speaks for 45 agents]

  YOU[You<br/>first Solution Architect<br/>no formal authority]

  YOU --> MAYA
  YOU --> DEV
  YOU --> TOMAS
  YOU --> PRIYA
  YOU --> LENA
  YOU --> IVAN
  YOU --> GRACE
  MAYA -.represents.-> GRACE

Who you have to reach, and what each of them controls. Note that “can stop it” and “has authority” are different groups.

How to use this page

• Treat these facts as given. Don’t add to them.
• If you need something that isn’t here, write down the assumption you’re making, in the artifact itself. That habit is worth more than the answer.
• Come back often. The numbers on this page are the ones your architecture has to satisfy, and vague memory of them produces vague architecture.

If you would rather use a system from your own work instead of Lintel, you can. It needs a real business driver with a number on it, stakeholders who disagree, a legacy component you can’t replace, a compliance constraint, and a plausible AI component. Without all five, several later modules lose their point.