Startup work

I know what the room feels like before the path is obvious.

Startup architecture means making consequential decisions with an incomplete map. Each case below is written as the decision it actually was, not the outcome it became.

These engagements demonstrate the architecture method; the first dedicated Inference Readiness Review will become the direct case study for this offer.

Anonymized startup engagement

An urgent founder objective, turned into a target architecture the team could execute safely.

full migration: 7 days
visible downtime: 0 min
team handoff: Full

Startup migration · Production path

7 days

01
Urgent founder objective
02
Target architecture
03
Agent-assisted execution
04
Acceptance gates

Ambiguous migration

Team-owned system

Context: A US-based Y Combinator startup needed its production stack off Vercel and Google Cloud and onto Azure, on a timeline set by the business rather than by engineering comfort.
Decision: Whether to move incrementally and carry two platforms for months, or define a single target architecture with acceptance gates and cut over once.
Constraints: No customer-visible downtime, a small team that still had to ship product, and no appetite for a migration that quietly became a quarter-long project.
Architecture: A defined target architecture, explicit acceptance gates per subsystem, and an agent-assisted execution path the engineering team ran themselves.
Tradeoffs: Chose one decisive cutover over a long dual-run: higher preparation cost, far lower carrying cost and ambiguity. Deferred optimization work that would have widened scope without reducing risk.
Result: The full stack moved in seven days with zero customer-visible downtime.
Ownership: A runbook and an operating approach the team kept using after the engagement ended.

Named client · Amplification Of Potential

A live-event AI system designed around the conversations it must never create.

p95 latency target: < 2.5s
inference budget / event: < $1
PII in model payload: Zero

AOP Beacon · Decision flow

Guardrailed

Phase objective

Guardrail policy

Few-shot + fallback

Private client render

Attendee selections

Safe conversation prompt

Context: AOP wanted AI-generated conversation prompts at live events, where the audience is present, the moment is unrepeatable, and a bad output is visible to everyone in the room.
Decision: How much to delegate to the model at all — and where a deterministic system had to remain in control of what an attendee could see.
Constraints: Under 2.5 seconds at the table, no attendee names in the model payload, no sensitive topics during the early event phase, and an inference budget that had to stay under a dollar per event.
Architecture: A phased experience model, a client-approved few-shot bank, explicit topic guardrails, a privacy boundary that keeps identity out of the payload by construction, and a deterministic fallback path.
Tradeoffs: Accepted a narrower generative range in exchange for bounded failure. Chose approved examples over open generation, and a deterministic fallback over a retry that could miss the moment.
Result: A reusable architecture for six active tables and up to 40 attendees, within the latency and cost envelope.
Ownership: Guardrail policy and prompt bank the client can extend without re-engineering the system.

Founder / operator proof

I also live with the decisions after launch.

Founder and operator

Presencia Loyalty

Built and operate a live wallet-based loyalty SaaS — a product whose architecture decisions I still live with every week.

Connected product experience

Junior Rodríguez × Presencia

Designed an NFC-enabled painting experience that joins a physical object, its story, and a shareable digital journey.