Open to SWE roles · Seattle / remote
Bil Enkhbileg
Software Development Engineer · Seattle, WA
Software engineer in Seattle. I design APIs, automate the boring parts, and ship interfaces people can actually use — currently at ConnectMNG, with a CS & Software Engineering degree from the University of Washington.
Capstone · CSS 497 · University of Washington
Ozora
A restaurant website, and the AI agent that runs its marketing.
Ozora Izakaya is a real Japanese izakaya opening in Bellevue. I was their engineer.
The first half of the capstone shipped the thing a restaurant obviously needs: a fast public website — menu, hours, reservations — plus an admin dashboard the owner can run without calling a developer. It is live, and it is multi-tenant, so a second restaurant launches from a config record instead of a code change.
The second half answered a harder question the owner actually asked for: independent restaurants pay for five or six marketing tools and still spend 8–15 hours a week doing it by hand. So I built Kairo — an AI agent the owner just talks to. "Friday looks slow, drum up some traffic." It drafts the Instagram post, the review reply, the win-back message, grounded in the restaurant's real sales data and written in their voice.
The rule that shaped everything: the agent only ever drafts. Nothing goes out to a real guest without the owner pressing approve.
How it works
- 01
The owner asks
A plain sentence in a chat box — "reply to the new Google reviews in my voice." No dashboard to learn, no fields to fill.
- 02
The agent works
Claude picks the right tool, pulls live context — guest counts, pending reviews, sales trends — and writes a draft in the restaurant's brand voice. Every call is written to an audit log.
- 03
The owner approves
Everything comes back as a draft. Nothing irreversible — no SMS, no post, no email — happens without an explicit yes.
- Live
- Public site + admin, on Vercel
- Tenants
- 2 seeded, ~40 menu items
- Schema
- 10 tables, tenant-isolated
- Agent tools
- 6 registered, 3 production
- Role
- Solo engineer
- Partner
- Real restaurant, real launch
- Next.js 14
- TypeScript
- Prisma
- PostgreSQL (Neon)
- Supabase
- NextAuth
- Claude API
- Tailwind
- Vercel
- Zod
- Vitest
- Playwright
Go deeper
The long version — the problem, the pivot that reshaped the quarter, how it's put together, and what held up under testing.
01 The problem Independent restaurants run on 3–9% margins and pay $300–$800 a month for tools they have no time to use.
US independent restaurants turn over roughly $300B a year on 3–9% net margins. The average owner is paying for five to seven separate SaaS products — POS, email, reservations, reviews, loyalty, a social scheduler, a website builder — and still puts in 8–15 hours a week on marketing and guest communication.
They do it badly, and not because they are careless: the tools do not share data, and nobody running a kitchen has time to become an operator of seven dashboards.
Three things made this solvable in 2026 rather than 2021 — LLM tool-use became reliable enough for owner-approved automation, Toast opened up a real webhook and API surface, and vertical AI agents for small-business segments started getting funded as a category.
02 The pivot The plan I walked in with was wrong, and a 90-minute phone call proved it.
Quarter two started as "add more features to the admin dashboard." Then I actually sat down with the owner for ninety minutes. He did not want a better dashboard. He wanted an AI system that would do the marketing.
My advisor put two questions to the original plan that it could not answer: what measurable outcome does this produce for the owner, and what is the single deliverable? The follow-up was blunter — you cannot build seven integrations in ten weeks solo, pick one thing and make it excellent.
I traded two weeks of feature work for a clean direction: one primary deliverable (the agent), one secondary deliverable already shipped (the website), and honest stubs for everything else. Shipping nothing new for a week to fix the direction was the most useful week of the quarter.
03 Architecture Two sibling Next.js apps: the restaurant website, and the agent. Deliberately not one codebase.
ozora-platform is a conventional full-stack Next.js 14 app — App Router server components render the public site, server actions handle every admin write, Prisma manages a Postgres schema on Neon, NextAuth handles login. Tenant brand colours flow through CSS custom properties set on <html>, so theming is data, not code.
The agent app is three layers. An owner surface (web chat, optionally Slack or SMS), an agent layer where Claude reasons and decides which tool to call, and a data layer of Supabase plus external integrations — Toast, Twilio, Google Business Profile, Yelp.
The agent loop itself is a classic tool-use cycle: send the message, history and a system prompt to Claude; Claude either answers or returns a tool_use block; execute the tool, hand the result back; repeat until there is a final answer. The system prompt is rebuilt every turn with the restaurant's name, city, brand voice and live sales context, which is what makes the answers specific instead of generic.
Splitting the agent into its own app was the decision that made the demo possible: the stub/real boundary is a clean seam, so the whole flow runs end to end without every integration being live.
04 Data model Ten tables, and a restaurant_id on every single one — designed before there was a single row of real data.
restaurants (one per tenant — slug, brand voice, Toast GUID, Google Place ID) · owners (staff, linked to Slack user ID for routing) · guests (profiles with SMS/email opt-in, birth month, last visit) · visits (tied to Toast order IDs) · campaigns (follow-up, birthday, lapsed 30/60/90, broadcast) · messages (SMS and email, in and out, with a status lifecycle) · reviews (Google/Yelp/OpenTable with reply tracking) · social_posts (draft → approved → posted) · agent_actions (immutable audit log) · integrations (per-tenant encrypted credentials).
Every data table carries a restaurant_id foreign key and no query can cross a tenant boundary through the application layer. That came from advisor feedback in week five — if you ever want a second customer, the database has to be multi-tenant from day one, because retrofitting it is painful. It cost about four hours up front and saved an unknowable amount later.
The schema is meant to be the restaurant's permanent customer data platform: guest data flows in through visits from Toast webhooks, and everything outbound flows out through messages and social_posts.
05 Testing Five integration test cases with pass/fail criteria — because "it seemed to work" is not a criterion.
With a real external API at the core, integration mattered more than unit coverage: what counts is whether chat → agent loop → Claude → Supabase holds together, not whether one function returns the right string in isolation.
TC-01 Instagram drafting — the response must contain a caption and a matching row must appear in agent_actions. Pass. TC-02 Review reply — verified against brand voice, and specifically must not open with "Dear", because a technically-correct corporate reply is still a failure. Pass. TC-03 Context query — the guest count the agent reports has to match what Supabase actually holds. Pass. TC-04 Toast webhook — a tampered payload must return 401, a valid one 200, with HMAC-SHA256 and a five-minute replay window. Pass. TC-05 Admin CRUD — NextAuth session through Prisma to the database and back onto the page.
The HMAC test was written as a curl command before the implementation existed, which is the cleanest way I have found to work out what a response should actually be.
06 Built vs. stubs Six tools registered. Three call Claude for real. Three return correctly-shaped placeholders, and say so.
Production: query_restaurant_context, draft_instagram_post, draft_review_reply — each makes a real Claude call with a brand-voice-tuned prompt and writes to the audit log.
Stubbed on purpose: list_lapsed_guests, draft_winback_sms, fetch_pending_reviews — architecturally correct, correctly shaped for Claude to reason about, waiting on the Toast and Twilio integrations.
The stubs are marked as stubs in the README and in a comment at the stub boundary in agent.ts. They are the physical record of scope discipline: every week produced a genuinely good new idea, and the MVP list was the thing that let me say "yes, but not now."
SMS sending was deliberately left unbuilt. The technical part is one HTTP request to Twilio; the TCPA and A2P 10DLC compliance around it is not, and getting that posture right before messaging a real guest was worth more than the feature.
07 Lessons Talk to the user first. Scope discipline is a technical skill. One engineer can ship more than they used to.
Talk to the user first. I planned a quarter of work without a direct conversation with the person I was building for, and one call invalidated most of it. It is a standard product lesson, but living it under real time pressure makes it stick differently than reading it.
Scope discipline is a technical skill, not a project-management platitude. The stubs in the codebase are what that discipline looks like when you write it down.
AI-assisted development changes the ceiling for a solo engineer. The scaffold — 24 files, roughly 1,800 lines — came together in a week, and patterns that used to mean days in documentation (Slack HMAC verification, the Claude tool-use loop, Supabase row-level security) took hours.
The hardest part was not code. It was deciding, mid-quarter, to abandon several weeks of planning and be explicit with my advisor about the trade I was making.
Selected work
Things I built, and what they changed.
Three projects that between them cover the stack I like living in — data in, services in the middle, something usable at the end.
- 01
r/WallStreetBets Sentiment Engine
An end-to-end pipeline that reads 30 days of retail-investor chatter and tells you which way the crowd is leaning on a given ticker.
- Scraped and normalized 30 days of r/WallStreetBets posts through the Reddit API, with ticker extraction and text preprocessing.
- Synthesized bullish / bearish / neutral training labels, then benchmarked Naive Bayes, Logistic Regression and Linear SVM against FinBERT and LLaMA-4.
- Compared classical baselines to transformer models on the same held-out set to quantify what the extra compute actually buys.
- Python
- pandas
- Reddit API
- scikit-learn
- FinBERT
- LLaMA-4
- 02
Podcast Automation Platform
A serverless content pipeline that took podcast publishing from a manual checklist down to a single upload.
- Designed RESTful services in Express.js backed by DynamoDB for metadata and S3 for media objects.
- Deployed behind AWS Lambda and API Gateway so the whole thing scales to zero between episodes.
- Cut manual content updates by 40% and removed the copy-paste steps that used to break every release.
- Express.js
- AWS Lambda
- API Gateway
- DynamoDB
- S3
- REST
- 03
Dairy Board of Mongolia
The public home of a national industry body — multilingual, content-heavy, and built to be maintained by non-engineers.
- Structured the information architecture across mission, strategy, projects, statistics and news.
- Worked directly with stakeholders to land multilingual content and the visual system.
- Integrated backend content features and shipped on Vercel.
- Vercel
- UX Design
- i18n
- Content Modeling
- Stakeholder Mgmt
About
I like the unglamorous half of engineering.
Most of what I've shipped is infrastructure that makes someone else's job shorter — a serverless pipeline that replaces a publishing checklist, a CI workflow that catches the bug before a human has to, a navigation bar that finally works on the phone people actually use.
I studied Computer Science & Software Engineering with Data Analytics at the University of Washington, after two years at Bellevue College where I spent a lot of time explaining pointers to other people — which turned out to be the fastest way to learn them properly.
Right now I'm at ConnectMNG in Seattle, working across Express services, AWS, and the front end. I'm most interested in backend and distributed systems, and in machine learning applied to messy, real-world text.
- June 2026 University of Washington
B.S. Computer Science & Software Engineering, Data Analytics
- March 2024 Bellevue College
Associate of Arts, Computer Science
-
0%
Lift in site engagement
after rebuilding mobile navigation
-
0%
Fewer manual updates
via the podcast automation pipeline
-
0+
QA hours saved monthly
from automated CI/CD checks
-
0+
Students mentored
in Python, Java and C++
Experience
Where I've been useful.
- Dec 2024 — Present
Software Development Engineer
ConnectMNG · Seattle, WA
- Designed and shipped a responsive mobile navigation system in HTML and CSS, lifting site engagement 25% and making the product usable for 50+ monthly visitors on small screens.
- Built a podcast automation platform on Express.js, DynamoDB and S3, deployed through AWS Lambda and API Gateway — cutting manual content updates by 40%.
- Stood up CI/CD pipelines in GitHub Actions covering build, test and deploy, reducing deployment time 30% and reclaiming 20+ hours of manual QA every month.
- Sep 2023 — Mar 2024
Computer Science Tutor
Bellevue College — Academic Success Center · Bellevue, WA
- Taught programming fundamentals and object-oriented design across Python, Java and C++.
- Coached 60+ students through debugging and writing clean, testable code, improving assignment completion and course outcomes.
- Partnered with ASC staff to redesign tutoring workshops, growing student participation and satisfaction.
- Sep 2022 — Jun 2023
President's Administration Assistant
Bellevue College · Bellevue, WA
- Reorganized 100+ internal documents under a consistent filing system, cutting retrieval time by 40%.
- Maintained digital records and reporting in Excel with consistency across files and schedules.
- Coordinated scheduling across executive teams.
Stack
Tools I reach for.
Comfortable across the whole path — from a Lambda handler to the chart it ends up in.
01 Languages
- Java
- Python
- C / C++
- JavaScript
- SQL
- R
02 Frameworks
- React
- Node.js
- Express.js
- pandas
- NumPy
- Flutter
- Appium
- unittest
03 Cloud & Data
- AWS
- Lambda
- API Gateway
- DynamoDB
- PostgreSQL
- S3
04 Tooling
- Git
- Docker
- GitHub Actions
- VS Code
- Figma
- Jupyter
- Tableau
Contact
Got something worth
building? Let's talk.
I'm open to new grad and software engineering roles, and I'll happily look at a contract project if it's interesting. Email is the fastest way to reach me.