Diagrams of small cloud systems.

Design walkthroughs of automations, DevOps, and infrastructure — each post centered on a diagram. Open to builds, collabs, and design reviews. By Allan Niñal.

  • A document expiry watcher on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small watcher that tracks every contract, certificate, insurance policy, license, lease, and software subscription your business renews; pings the right owner with full context before each one lapses; escalates if nobody acts. The owner can renew, snooze, or ack-only directly from the alert. The whole system on one page.

  • How an item gets tracked

    Part 2 of 7 · ~4 min read

    Three lanes feed the registry — the Drive sheet itself, an inbox-forwarding lane that uses Textract and Bedrock Haiku to propose rows for one-tap approval, and an hourly calendar import for events tagged #expires.

  • How the watcher knows when to alert

    Part 3 of 7 · ~5 min read

    A daily tick reads the registry, computes days-to-expiry per item, compares against per-category window chains in the rules doc, and picks one of four moves: healthy, first alert, reminder, escalate. No model on the tick.

  • How an alert finds the right person

    Part 4 of 7 · ~5 min read

    Owner resolution per item, quiet hours, holiday calendars, Slack DMs with full context, email fallback, and the four guardrails between the watcher’s chosen move and the actual ping landing.

  • How an item gets renewed

    Part 5 of 7 · ~5 min read

    Three actions on the Acknowledge button: renew (new expiry, fresh chain), snooze (delay, capped at three per chain), and ack-only (silence the chain without changing the expiry). Every action is logged.

  • What the expiry watcher costs

    Part 6 of 7 · ~3 min read

    Pennies a month at SMB volume. The watcher runs once a day, calls no models on the tick, and only fires Bedrock on the inbound parsing lane and the monthly summary.

  • Engineering reference: the expiry watcher architecture

    Part 7 of 7 · ~8 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, EventBridge Scheduler config, and the DynamoDB schemas.

  • A quote drafter on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small drafter that catches every incoming RFQ from your website form, sales inbox, or direct file uploads; extracts the line items against your catalog; prices each one against your rules; drafts a complete quote with a cover paragraph in your voice; and parks it in front of a rep for one-tap approval. Drafts never auto-send. The whole system on one page.

  • How an RFQ reaches the drafter

    Part 2 of 7 · ~4 min read

    Three lanes at the door — the website RFQ form fast path, the shared sales inbox via SES, and direct uploads through a presigned S3 portal. Dedupe and screen happen before any AI runs.

  • How the drafter reads an RFQ

    Part 3 of 7 · ~5 min read

    Three small extractors run in parallel: line items, constraints, context. Plus a catalog lookup grounded in a Bedrock Knowledge Base. Confidence on every field; borderline becomes the clarify move.

  • How a quote gets priced

    Part 4 of 7 · ~5 min read

    A five-stage pricing pipeline runs per line: base price, tier discount, volume break, regional, bundle. Every applied rule cites the catalog row or rules section that produced it. The engine never invents a number.

  • How a draft stays honest

    Part 5 of 7 · ~5 min read

    Four guardrails sit between the model and the rep’s queue — citation required, no fabricated SKUs, no commit on availability, discount cap. A draft never auto-sends; the rep’s approval is the only path to the customer.

  • What the quote drafter costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB RFQ volume. Pennies per RFQ, dominated by Bedrock tokens for the extractors and the cover-paragraph composer.

  • Engineering reference: the quote drafter architecture

    Part 7 of 7 · ~9 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Knowledge Base wiring, SES inbound, presigned-upload flow, PDF rendering, IAM scopes, and CRM destinations.

  • A lead intake bot on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small intake bot that catches every new lead from your forms, ad platforms, and inbox, qualifies it against your ICP, instantly routes the hot ones to the right person with full context attached, and quietly drops the cold ones into a nurture queue. The whole system on one page.

  • How a lead reaches the intake bot

    Part 2 of 7 · ~4 min read

    Three lanes at the door — a website-form fast path, an ad-platform push from Meta and Google Ads, and the shared sales inbox via SES. Dedupe and screen happen before any AI runs.

  • How the bot reads a lead

    Part 3 of 7 · ~5 min read

    Three small extractors run in parallel: intent, urgency, fit signals. Plus a free passive enrichment from the email domain. Confidence on every field; borderline becomes a draft.

  • How the bot scores and routes a lead

    Part 4 of 7 · ~5 min read

    Four moves, one pick per lead: hot route, warm follow-up, nurture, reject. Two override gates fire first; round-robin assignment respects on-call hours.

  • How a reply stays on policy

    Part 5 of 7 · ~5 min read

    Three Drive docs ground the composer; four guardrails sit between the model and the send button — citation, no fabricated specifics, no commit on availability, no PII in subject lines.

  • What the lead intake bot costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB lead volume. Pennies per lead, dominated by Bedrock tokens for the extractors and the composer.

  • Engineering reference: the lead intake bot architecture

    Part 7 of 7 · ~6 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Knowledge Base wiring, Meta Lead Ads and Google Ads API specifics, SES inbound, CRM destinations.

  • A review responder on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small responder that watches every new review across your platforms, drafts replies in your voice from your own policies, posts the safe ones automatically, and hands you the rest with everything you need to respond in one sitting. The whole system on one page.

  • How a review reaches the responder

    Part 2 of 7 · ~4 min read

    Three lanes at the door — Google Business Profile push, Facebook page reviews push, Yelp poll. Dedupe and screen happen before any AI runs.

  • How the responder reads a review

    Part 3 of 7 · ~5 min read

    Three small extractors run in parallel: rating with sentiment cross-check, themes, and specifics like names and dishes. Confidence on every field; borderline becomes a draft.

  • How the responder picks a move

    Part 4 of 7 · ~5 min read

    Four moves, one pick per review: auto-reply, draft, escalate, ignore. Safety keywords bypass everything; named staff and specifics become drafts.

  • How a reply stays in your voice

    Part 5 of 7 · ~5 min read

    Three Drive docs ground the composer; four guardrails sit between the model and the post button — citation, no PII echo, no fabricated specifics, no off-policy promises.

  • What the review responder costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB review volume. Pennies per review, dominated by Bedrock tokens for the extractors and the composer.

  • Engineering reference: the review responder architecture

    Part 7 of 7 · ~6 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Knowledge Base wiring, Google Business Profile and Meta Graph API specifics.

  • A website chat assistant on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small chat widget that lives on your website, answers visitors from your own knowledge in real time, hands the rest to a human cleanly, and quietly logs every miss for next week’s review. The whole system on one page.

  • How a conversation starts and stays alive

    Part 2 of 7 · ~4 min read

    Connect, exchange, idle. A websocket and a small scratchpad — that’s the whole shape. Short-term memory only.

  • How the assistant answers

    Part 3 of 7 · ~5 min read

    Four tools, one pick per turn: answer, clarify, hand off, decline. No citation, no auto-answer.

  • How a handoff to a human works

    Part 4 of 7 · ~4 min read

    Tell, package, deliver, hold. The visitor never repeats themselves to the human; the transcript is the ticket.

  • How gaps become better answers

    Part 5 of 7 · ~4 min read

    A small clockwise loop — log every miss, group similar questions, write a paragraph, re-index automatically. Ten minutes a week makes month two’s assistant meaningfully better.

  • What the chat assistant costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB volume. Cents per conversation, dominated by Bedrock tokens for the answerer.

  • Engineering reference: the chat assistant architecture

    Part 7 of 7 · ~5 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Knowledge Base wiring.

  • A booking assistant on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small assistant that reads appointment requests, checks your Google Calendar, proposes slots that respect your service rules, locks in the customer’s pick, and sends quiet reminders. The whole system on one page.

  • How a booking request reaches the assistant

    Part 2 of 7 · ~4 min read

    Three lanes at the door: a web-form fast path for the easy 80%, an AI-handle path for free-text email, and a direct escalate for VIPs the AI should never touch.

  • How the assistant understands the request

    Part 3 of 7 · ~5 min read

    Three small extractors run in parallel: which service, when roughly, and who’s booking. Confidence on every field; anything borderline becomes a draft.

  • How the assistant picks slots

    Part 4 of 7 · ~5 min read

    Five filters in order: calendar query, working hours, duration plus buffers, blackouts and capacity, then rank. Every constraint comes from your rules file.

  • How a booking gets confirmed

    Part 5 of 7 · ~5 min read

    Claim, write, confirm, remind — in that order. An atomic claim row prevents double-booking even when two customers click at the same second.

  • What the booking assistant costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB volume. Cents per request; the form lane is essentially free.

  • Engineering reference: the booking assistant architecture

    Part 7 of 7 · ~4 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Google Calendar API choices.

  • An email assistant on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A small assistant that reads your inbox, drafts replies from your own knowledge, and escalates anything beyond its remit to a human. The whole system on one page.

  • How an email enters the assistant

    Part 2 of 7 · ~4 min read

    Three lanes at the door: auto-archive for newsletters and bots, AI-handle for normal mail, direct escalate for the people you always want to see.

  • How the assistant reads an email

    Part 3 of 7 · ~5 min read

    Strip the noise — quoted threads, signatures, footers, trackers — and what’s left is the real message. The brain only sees the clean version.

  • How the assistant decides what to do

    Part 4 of 7 · ~5 min read

    Four tools, one pick per email: answer directly, draft for review, escalate to a human, or archive without replying. The AI never invents.

  • How a reply stays accurate

    Part 5 of 7 · ~5 min read

    Every auto-reply cites a passage from your knowledge file. No citation, no auto-send. Borderline confidence routes to a draft you approve in seconds.

  • What the email assistant costs

    Part 6 of 7 · ~3 min read

    A coffee a month at SMB volume. Cents per email, not dollars.

  • Engineering reference: the email assistant architecture

    Part 7 of 7 · ~3 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs.

  • A voice agent on AWS for the price of a phone plan

    Part 1 of 7 · ~5 min read

    A small voice agent that answers your business phone, replies from your own knowledge in real time, and politely passes the rest to a human.

  • How a call connects

    Part 2 of 7 · ~4 min read

    Three ways a call can go: voicemail after hours, AI session in business hours, or direct human transfer for VIPs.

  • How the listener hears

    Part 3 of 7 · ~5 min read

    Streaming transcription, partial guesses refined live, locked the moment the caller pauses.

  • How the brain decides what to say

    Part 4 of 7 · ~5 min read

    Four tools, one pick per turn: answer, book, transfer, end. The AI never invents.

  • How the speaker stays natural

    Part 5 of 7 · ~5 min read

    The latency budget for a one-second-or-less reply. Where each millisecond goes.

  • What the voice agent costs

    Part 6 of 7 · ~4 min read

    Phone-bill territory. The phone number is the floor; everything else scales with how often it rings.

  • Engineering reference: the voice agent architecture

    Part 7 of 7 · ~3 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs.

  • A document pipeline on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    A serverless pipeline that reads documents for you, checks each one, and sends the structured data straight to wherever it needs to go. The whole system on one page.

  • How a document enters the pipeline

    Part 2 of 7 · ~4 min read

    Three ways in — uploaded, emailed, or dropped. One shared place after intake, screened for trouble before any AI runs.

  • How the AI reads a document

    Part 3 of 7 · ~5 min read

    Two AIs in sequence — a specialist for layout, a generalist for meaning. The combo is more accurate than either alone.

  • How extraction stays accurate

    Part 4 of 7 · ~5 min read

    The validator gates obvious cases through and queues the unsure ones for a 5-second human review. Wrong values never quietly slip into your tools.

  • How the data flows out

    Part 5 of 7 · ~4 min read

    Each destination is a small pluggable piece. The rules file decides which document type lands in which tool.

  • What the document pipeline costs

    Part 6 of 7 · ~3 min read

    A coffee a month at typical SMB volume. Cents per document, not dollars.

  • Engineering reference: the document pipeline architecture

    Part 7 of 7 · ~3 min read

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs.

  • A daily briefing bot on AWS for a few dollars a month

    Part 1 of 7 · ~5 min read

    An automated digest that watches the sources you care about and emails you the few items worth your time. The whole system on one page.

  • How the ingestor walks your sources

    Part 2 of 7 · ~4 min read

    A small dispatcher reads your source list, hands each source to a specialist worker, and drops everything new into one shared place. Three workers, one mailbox.

  • How the bot picks what matters

    Part 3 of 7 · ~5 min read

    Three filters in order, cheapest first. Most items die at the free filter; the smart AI only sees the few borderline cases.

  • How the digest gets delivered

    Part 4 of 7 · ~3 min read

    Five short blocks in your inbox at 7am — or nothing on quiet days. The bot never trains you to ignore it.

  • How you change what the bot watches

    Part 5 of 7 · ~3 min read

    Two short Drive docs are the entire interface. Edit, save, the bot picks up the change tomorrow. No deploy, no terminal, no waiting on anyone.

  • What the briefing bot costs

    Part 6 of 7 · ~3 min read

    A coffee a month, possibly less. Where the dollars actually go in a serverless briefing bot on AWS.

  • Engineering reference: the briefing bot architecture

    Part 7 of 7 · ~3 min read

    Same system as the rest of the series, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, and the actual flow operations — everything you’d need to recreate this in your own AWS account.

  • A Facebook autoposting system on AWS for $2–$5 a month

    Part 1 of 7 · ~5 min read

    A scheduled Facebook poster that stays on-topic, answers questions correctly from a Google Drive knowledge base, and doesn’t surprise you with a huge cloud bill. The whole system on one page.

  • How code becomes a working system

    Part 2 of 7 · ~3 min read

    Push to GitHub, walk away. The cloud handles the rest — and never holds a long-lived password.

  • How a post actually goes out

    Part 3 of 7 · ~4 min read

    Five quick checks between “it’s time” and “post is live.” Cheap gates first, expensive gates only when needed.

  • How the Drive folder powers everything

    Part 4 of 7 · ~4 min read

    The client edits a Google Doc. The system updates itself — with a safety layer that keeps the old version live if anything looks broken.

  • How replies work without making things up

    Part 5 of 7 · ~5 min read

    The bot answers from the client’s docs only — or escalates to a human. Citation required, no exceptions.

  • What this all costs

    Part 6 of 7 · ~3 min read

    A coffee a month, not a Netflix subscription. Line by line, where the dollars actually go.

  • Engineering reference: the full architecture

    Part 7 of 7 · ~3 min read

    Same system as the rest of the series, drawn purely for engineers. Service names, resource identifiers, region, and the actual flow operations — everything you’d need to recreate this in your own AWS account.