I build the systems behind the AI.

01The problem

Budgeting apps track spending; they don't plan meals

Generic budget trackers tell you afterwards that you went over, which is no use when the question is what to cook tonight. The real constraint is that the last week of the month is the problem, not the first — and planning it well requires knowing what a dish actually costs before you walk to the market, not after you get home.

• The failure mode is discovering the money is gone on the 25th
• A generic tracker reports overspending after the fact
• Recipes written for four mean waste or four nights of the same adobo

02The design

The budget becomes the plan, and the plan is priced per plate

You enter a monthly food budget, how many people you're feeding, and where you shop. That divides into a daily cap, and the planner fills seven days of ulam against it, pricing every single plate. Meals get ticked off as you cook and gastos get logged as you spend, so the plan follows real life instead of fighting it.

• Budget, household size, and region in, seven days of ulam out
• Every meal priced, all of it inside the daily cap
• Survival bar tracking the month, and a tipid tally for what's saved

03The hard part

No invented pesos

A meal planner that guesses prices is worse than useless — the entire value is that the number matches what your market charges. So costs come from real price observations collected per region and reduced to medians, and every dish shows how much of its cost is measured versus estimated. Where coverage is thin, the app says so instead of inventing a figure.

• Price observations collected per region, costed against medians
• Six regions compared live, so prices match where you actually shop
• Measured versus estimated cost shown per dish
• Unpriced lines are labelled, never guessed

04The shape of it

One arithmetic, four very different households

The maths is identical every time; only the number going in changes. A minimum-wage earner feeding a family needs the month held to a daily allowance so the 20th is a thinner week rather than a crisis. Someone living alone needs single-serving quantities, because a recipe for four is either waste or the same adobo four nights running. A bigger household needs batch planning, so one pot becomes four chances to be eaten on four different days.

• Minimum-wage earner, whole family: a daily allowance that holds
• Living alone: single-serving quantities and a pantry that remembers
• Budget shrank: re-cost the plan and swap the expensive dishes
• Six or seven at the table: plan around batch cooking

05Where it is

Early access, labelled honestly

v0.3.0 ships as a signed Android release build, free during early access, with iOS in progress and store listings pending. Distribution is a direct APK for now, and the site says plainly which pieces are live, which are coming, and where price coverage is still thin — because the audience is people deciding whether to trust it with their budget.

• Signed release build, Android 7.0 and up
• Free during early access, no account or card needed
• The site carries a working budget demo built from the app's own dish data

01The problem

Execution logic was being rewritten in every project

Every product I built needed the same primitives: run a job, retry it, observe it, and know what it did. Each implementation started from zero, and each one started with the same class of bug — work that silently disappeared, retried twice, or ran with no trace of what happened.

• No shared contract between scheduled work and request handling
• Retries and failure states lived in application code
• No consistent way to answer what ran, when, and why it failed

02The design

One execution substrate, separated from any single product

Tukma splits the control plane from the execution runtime. The control plane owns scheduling and state; workers own execution and stay independently scalable. That boundary is what lets the same platform back a web request, a cron job, or an agent step without special cases.

• Control plane owns scheduling, state transitions, and durable queues
• Workers pull work, execute, and report outcomes
• PostgreSQL as the durable source of truth rather than in-memory state

03The build

Go's concurrency model is the whole design

Worker pools, bounded queues, and cancellation are the primitives the platform is built on. Context propagation means a cancelled job stops doing work instead of finishing quietly, and the concurrency primitives are explicit enough that backpressure is visible rather than emergent.

• Bounded worker pools with explicit backpressure
• context.Context threaded through every cancellable operation
• Testable internals: the hard logic is isolated from HTTP handlers

04Where it is

Early, but the foundation is real

Tukma is in active development. The direction is settled and the foundation is being built to be tested rather than demoed — the goal is a platform that stays boring under load.

01The problem

LLM costs were growing faster than usage

The product worked, but every AI feature scaled its own bill. Prompts were longer than the task required, retries were unconditional, and overlapping features were paying separately for reasoning the platform could have done once.

• Oversized prompts sent on every request regardless of task
• Retries without backoff or a cost ceiling
• Duplicate model calls across features that shared context

02The approach

Treat inference cost as an engineering constraint

The fix was structural rather than clever. Prompts were scoped to the smallest task that satisfied them, results were structured so they could be cached and reused, and retries became conditional on whether the request could plausibly succeed.

• Tightened prompts and scoped them per feature
• Structured output so results were cacheable and reusable
• Retry policies with backoff and explicit failure conditions

03The outcome

More than 80% less AI and API spend

Same product surface, same output quality, roughly a fifth of the previous inference cost. The work also made the AI features predictable to reason about, which mattered more than the savings for shipping new ones.

04The stack

Django and React, with Vertex AI behind structured workflows

A Django backend owning domain, analysis, and lead data, paired with a React interface and Vertex AI powering the generation and analysis features. Structure came from the model layer, not from post-processing.