The way you think about AI is the architecture of your product.

Ship UI fast, figure out the data shape later, refactor as you learn.

Every feature for the next two years fights the wrong shape. The 'small refactors' compound into a rewrite that nobody schedules.

Spend the first week drawing tables, foreign keys, and history columns. The schema you commit to defines the products you can ship and the products you can't. Treat it like the most important code you write — because it is.

Prototype single-tenant, add tenant scoping later when there's a paying customer.

The retrofit is a complete rewrite by another name. Every window where tenancy is not enforced is a window where customer data can leak across boundaries.

Add org_id and a row-level security policy to every table the day it's created. Audit the runtime context of every query path before launch. There is no 'temporary' single-tenant phase that survives contact with a real customer.

Spend the engineering budget on the bidirectional audio plumbing because it's what's new and unfamiliar.

Audio works perfectly while the model says the wrong thing. The user hears 'inside mount' interpreted as 'outside mount' and never trusts the system again.

Spend 80% of the build on system prompts, tool schemas with strict types, refusal-on-uncertainty patterns, and domain grounding. The protocol is one library import; the judgment is the product.

Agent generates, human edits. Treat AI output as a fast first draft.

The human becomes a slow ranker for a fast generator. The job becomes drudgery, and the AI gets credit for work the human is doing.

Require every agent output to come with a self-assessment — confidence, citations, structured rationale. Score it against thresholds. Below threshold, send it back with a critique instead of forwarding to the operator. The human's job becomes adjudicating disputed cases, not editing every line.

Pick one frontier model and build everything against its SDK. The provider's SLA is the answer.

When the provider is down, your product is down. When a model rev quietly regresses on the task you depend on, your quality drops and you don't know why.

Route per task by capability, latency budget, and cost ceiling. Log which model produced which output. Watch for quality regressions. Have a fallback chain. Treat the LLM layer the way you'd treat any other critical dependency — with redundancy and observability.

Log LLM calls the way you'd log API calls — duration, status, error rate.

When something goes sideways in production, there's no replay. No eval set. No way to tell whether quality regressed because of the model, the prompt, or the data. No fine-tuning signal when you eventually want one.

Persist the full prompt, the full response, every tool call, and the orchestration state alongside the conventional metrics. Treat AI traffic as a corpus that's worth more than the requests it served.

Pick a new database, a new framework, a new deploy target — innovation everywhere.

Reliability suffers, shipping speed suffers, and the user never sees any of the cleverness because it's all in plumbing.

Pick mature, well-understood infrastructure for the parts that aren't your differentiator — the database, the framework, the deploy target. Reserve the novelty budget for the AI surface — the part the user actually touches and remembers. Innovation is a finite resource; spend it where the customer feels it.

Cosine similarity on embeddings, sort, ship.

You confidently surface 'semantically similar' results that fail hard constraints — wrong location, wrong work authorization, wrong required skill. Users learn to distrust the ranking.

Treat the embedding score as a candidate generator. Re-rank with structured filters and operator-set must-haves. The product is the re-rank layer, not the embedding.

Scale the team to scale the output. More engineers, more progress. Hand the work off through layers of coordination.

AI development moves too fast for handoff overhead. The expensive resource is the speed of converting a clear thought into shipped code — and that speed dies in coordination, in offshoring, in handoffs from senior partners to juniors.

Senior practitioners holding the whole problem, writing the code across stacks, deciding what to cut. The leverage isn't in capacity. It's in the absence of handoffs and the presence of judgment at every step.

Build the success state, treat the rest as error handling, ship.

AI fails differently than software — quietly, plausibly, often confidently. The first time the system surfaces a confidently-wrong answer with no graceful path, the user's trust collapses and doesn't recover.

Design the refusal, the degraded mode, the timeout, and the fallback as first-class user experiences. What the system does when it doesn't know, can't answer, or runs out of time is part of what you're shipping. Treat it that way.

Iterate on the prompt until it looks good to the developer running it. Ship.

Quality regressions become invisible. Model revs surprise you. When a stakeholder asks 'is this actually working?' you have a vibe, not data. You can't tell whether your last prompt change made things better or worse.

Define the evaluation set and the scoring criteria before writing the prompt. Run every candidate against it — current vs. next prompt, current vs. next model. Quality becomes something you measure and improve, not something you assert and defend.

Prototype on the most capable model, ship to production unchanged, watch the bill arrive.

AI costs scale with usage in ways traditional software doesn't. A feature that costs nothing in development can be unprofitable at customer scale — and refactoring for cost after launch is a rebuild by another name.

Decide at design time which tasks deserve the frontier model and which can run on a smaller one. Cache aggressively where the input space allows it. Route by capability, latency budget, and cost ceiling. Treat token budgets the way you'd treat any other engineering constraint — with seriousness.

Optimize for accuracy on the eval set; ignore whether the model's confidence is well-calibrated.

The system confidently lies. The few high-stakes mistakes outweigh the many ordinary successes. Users — once burned — distrust everything the model says, including the things it gets right.

Use prompts and tooling to make the model express uncertainty honestly. Surface that uncertainty in the UI. An 'I'm not sure, ask a human' response is a product feature, not a failure mode. Calibration is what makes a probabilistic system worth trusting at all.

Ship the feature, figure out monitoring, alerts, and on-call later.

The first incident reveals there are no logs, no rollback, no playbook, and no clear way to diagnose. The clock keeps running while the team flails. Confidence — internal and external — takes the hit.

Operability is part of done. Logs, dashboards, runbooks, and a tested rollback path before launch — not after. If you can't articulate how you'd debug a production incident at 2 AM without calling a meeting, you're not done shipping.