01
Understand the problem first.
A lot of software trouble comes from forcing a familiar pattern onto a problem that doesn’t quite fit. We try to understand the shape of the work before we pick tools — and we’re comfortable saying we don’t know yet.
Vol. 01 · Iss. 04Spring · MMXXVI
Available for new work
Software,
grown with
care.
Fruit Cloud Co. is a small independent technology studio. We help teams build AI-native applications and the cloud infrastructure to run them well — and we’re happy to say no to projects that aren’t a fit.
- Practice
- AI · Cloud · Product
- Founded
- 2024
- Based
- California.
- AI engineering
- Cloud architecture
- Applied research
- Product design
- Data systems
- Quiet software
- Patient engineering
- AI engineering
- Cloud architecture
- Applied research
- Product design
- Data systems
- Quiet software
- Patient engineering
§ 01
Field
notes.
— A short manifesto in three parts.
02
AI where it actually helps.
Models are useful when they remove drudgery or surface structure that’s otherwise hard to find. We aim for AI features that earn their place in the product, not demos that look good for a week.
03
Boring decisions, made carefully.
Most of the work that keeps systems healthy isn’t glamorous: choosing the right boundaries, writing legible code, picking the unfashionable tool when it fits better. We try to take those small decisions seriously.
§ 02 — The Practice
What we’re
good at.
— Practice 01i.
AI-native product engineering.
Designing and shipping AI features end-to-end — picking the right model, building evaluation, and getting the user-facing details right so the result feels useful day to day.
- Agents
- RAG
- Evals
- LLM apps
— Practice 02ii.
Cloud-native architecture.
Designing infrastructure that’s simple to operate: predictable costs, observability that answers real questions, and migrations planned in steps rather than big bangs.
- GCP
- AWS
- K8s
- Edge
— Practice 03iii.
Data & ML platforms.
The pipelines, feature stores, and evaluation harnesses underneath any serious ML effort. Less exciting than the model, but usually where projects succeed or stall.
- Pipelines
- Vector DBs
- Streaming
— Practice 04iv.
Technical strategy.
A second pair of eyes for architecture reviews, build-vs-buy decisions, and roadmap tradeoffs. Useful when you want a candid outside read before committing.
- Advisory
- Reviews
- Roadmaps
§ 03 — Rhythm
A working
cadence.
A simple four-step rhythm. Most engagements look something like this — adjusted to fit the work in front of us.
- Beat II
Listen.
We start with conversations and reading the existing code, then write up what we’ve understood so we’re working from the same picture.
- Beat IIII
Sketch.
A short proposal covering the scope, the parts we think matter most, and what we’d intentionally leave out for now.
- Beat IIIIII
Build.
Code lands in your repo from day one, with regular check-ins. We share what’s working and what isn’t along the way.
- Beat IVIV
Hand off.
Documentation aimed at the next engineer who has to read it. We stay reachable for questions afterwards.
— Closing —§ 04
If this sounds
like a fit,
let’s talk.
A few sentences about what you’re working on is plenty to start. We read every note ourselves.