Things I've built.

Problem

Coordinators had four tabs and four ids for one patient. Each system named a patient its own way: the intake survey by response id, the estimator by its own number, the consult grader by Zoom meeting, the experience survey by email. The Denticon id sat in three of them as a hand typed field nothing checked, so it joined nothing.

Solution

Two Cloud Run services from one image. The dashboard, behind Google sign in limited to the company domain, holds no Denticon credentials; a sync service that serves no pages holds them. Webhooks and three scheduled jobs keep a Firestore mirror of offices, providers, patients and appointments current, and a registry API with one secret per caller serves it to the estimator and the capacity planner. Profiles join linked records on the Denticon id at read time.

Process

The vendor API has no patient search, so the mirror is the only patient index there is. It also ignores unknown query parameters and returns the whole table with a 200, so a parameter is allowed only once it is proven to change totalCount. The record matcher was attacked from three angles before it could write, ran in shadow mode, and refuses when unsure. A person's decision always wins: each link write is a transaction that decides again on fresh documents, and every link is versioned, audited and undoable. A journey step with no linked chart reads as unknown.

Result

Started in June 2026 and rebuilt around the Denticon API in September; the sync read the live practice on 29 September. Once the sync ran on a timer the mirror went from 6.0 days behind to 2.6 minutes behind, the linker picked the right chart 453 times out of 453 in a blind test against bookings, about four in five intakes link to their chart on their own, and the capacity planner reads the registry every minute.

Problem

Staffing for three offices lived in the operations lead's workbook: twenty pasted copies of the same week. Fixed ranges undercounted silently when a row landed outside them, typing over a formula deleted it, and time off entered later never changed the plan. The real cost was last minute coverage calls, and a doctor slammed at one office while another had a free chair.

Solution

A pnpm monorepo: a pure TypeScript engine package with no I/O, and a Next.js 16 app on Cloud Run with Cloud SQL Postgres, Drizzle and Google sign in. The same engine runs in the minute sync and in the browser for instant what if changes, golden tested against the workbook. Bookings come from Denticon through the patient dashboard's registry, so the planner holds no vendor credential and only reads.

Process

Read only is a type level test: the appointment source may have no member named like write, create, update, delete, cancel or book. A mass cancel guard stops any sync that would cancel an office's bookings in bulk and changes nothing, after a silently dropped office code nearly did exactly that. Sync failures return 200 so the scheduler does not retry storm, and staleness shows on a status pill. Cover suggestions rank five keys (capability, willingness, presence, free day, pairing), and every reason shown comes from the rule that produced it.

Result

v0.1.0 reached production on 28 September 2026, 17 days after the first commit, and the first full read of live Denticon data landed at 5:34 the next morning. The operations lead and the office directors plan from it every day, with a Room Board since 20 October and a 7 AM weekday email of what needs action. It cost $27 to run from October 1 to 28, measured.

Problem

Consult reviews were written by hand against the CEO's seven criterion Word document, and nothing graded every consult.

Solution

One Cloud Run service in Python. A Zoom webhook starts it when a transcript is ready; it checks the signature, finds the doctor, and asks Vertex AI Gemini 2.5 Pro for a scorecard as JSON against a versioned rubric prompt and schema. Every rationale must quote the transcript with a real timestamp, and each score is colored against that doctor's own 30 day average before the report and PDF go out.

Process

The doctor is found in three layers: Zoom participants against the doctor directory, then transcript speaker labels, then the names Gemini pulls out while scoring. A response that did not finish cleanly is never accepted, and the token budget doubles on a retry. Instead of Workspace domain wide delegation, the pipeline uses an OAuth grant kept in Secret Manager.

Result

471 consults scored live from May 19 to Oct 28 across three offices; median 2.7 minutes from transcript to sent report in October. 392 older consults from November 2025 to May 2026 were regraded on the same rubric, so the trends start in November.

Problem

An earlier n8n grader proved the idea. Every hour it scored calls as a flat sum out of 60, wrote each result into a Google Doc and emailed a link. It kept no database, so no coordinator had a trend, and no quote stood behind a score.

Solution

A full rebuild on Google Cloud. Every five minutes from 6 AM to 6 PM a Cloud Run Job takes the new recordings from the phone system's SFTP drop, transcribes them with Vertex AI Gemini, keeps the new patient calls, and grades each on six criteria with a transcript quote behind each score, plus three hard gates. Verdicts land in BigQuery, and each coordinator gets the report by email.

Process

The model returns integers and gate answers; plain Python does the 40/40/20 math, so the same verdict always gives the same score. Hard gates show as a flag beside the score. A run lease stops overlapping runs from grading or emailing a call twice.

Result

690 real calls graded from June 17 to October 29, out of 28,745 recordings the poller read; a median 14 minutes from the end of a call to its grade in October. Live calls were graded 16 days after the first commit. Live on Cloud Run behind Google sign in.

Problem

Coordinators quoted from one shared price list with no office prices or tiers. The six month price promise was a line on the PDF, and nothing held a saved quote to it.

Solution

Next.js 16, Postgres and Drizzle. Five pricing model kinds (flat, tiered, tiered by zone, price range, per surface), and every saved line keeps its captured price, tier, label and price book version, so a later price change never reaches a saved quote. Each office has its own versioned price book, and only an admin publishes a change.

Process

Nine architecture decisions written on May 6, before any code. The pricing engine tests reached full coverage at 2:32 AM on the first night, and v1.0.0 shipped 14.5 hours after the first commit. A list of questions with worked numbers let the practice review pricing without reading code.

Result

Live since May 8, 2026. Since then: a drag and drop workspace with phases and scenarios, an Excel export that matches the coordinator's own file, a landing page that is the day's consult schedule, visit sequences built from the estimate, the Hybridge design in one day on September 29, and reopening a presented estimate as its next revision on October 28. It cost $34 to run from October 1 to 28, measured.

Problem

The pre consult assessment ran on a third party intake platform. The practice did not own its patients' answers, one person could edit a question or add a recipient, and each report was filed by hand.

Solution

An intake and experience survey owned by the practice on Google Cloud. Each submit becomes one Cloud Task for the renderer, which draws the patient summary and the doctor report, with Gemini writing the psychographic and reading the panorex. The governing rule is AI assists, doctors validate.

Process

Our founder walked me through four cases, narrating every call. I turned the narration into a written ruleset where each rule cites its case and timestamp, and implemented it as a Gemini read with structured output: the model lists the teeth, and plain code recomputes the score. Every Gemini call goes through one chain of retries and newer fallback models inside a time budget.

Result

Patients at all three offices fill in the intake before a consult. The founder's review of the first reads shipped as ruleset v2 on 8 July, and since 23 October the clinic email goes out with both reports or waits.

Problem

Lead forms on our websites had to keep every inquiry, protect patient privacy, work on a phone, land on the Monday board, and handle conditional questions and spam.

Solution

One owned platform: a public forms app with an embed script, a delivery worker that puts each inquiry on the Monday Leads board and emails the copies, a dashboard and form builder behind IAP, and nightly checks.

Process

Built around one rule: no submission is ever lost. If Firestore fails, the answers go to a private Cloud Storage bucket and the visitor still sees success. If both fail, the server answers 503 and the browser retries over about 15 seconds with the same id, then keeps the answers on the device. A queue task wakes the worker on every send, and a sweep runs every minute.

Result

Live since 6 October 2026. Elmwood's contact form has run on it since 14 October, and on 26 October all six tracking fields reached the Monday board, and the 67 leads already there got their missing ones.

Problem

Hybridge runs three offices and its own lab on systems that do not talk to each other: Denticon for charts and bookings, Monday for leads and patient boards, Zoom for consults, a phone system that records calls, the lab's case and scan systems, and a lot of spreadsheets. Every team brought one problem.

Solution

Solve each problem where the data already lives. Three shared services carry the most weight: the Denticon sync keeps a copy of Denticon, the CDF registry serves it to other apps, and the PDF renderer turns surveys into reports.

Process

One service holds the Denticon credentials, and the apps that need it read the mirror. Six apps file feature requests through one relay into one list, and a request filed on October 28 was live 19 minutes later.

Result

45 live services in 14 Google Cloud projects on October 29, 2026. The six projects the billing export measured cost $132 from October 1 to 28.

Problem

Coordinators wrote each patient's visit plan by hand in Word, copied from master documents in Drive. Every change meant renumbering the visits and redating everything after it by hand, on a case that can run for months.

Solution

Two packages. sequence-core holds the domain model, the practice masters stored as data, generation from an estimate, date and wait arithmetic, and the Word and text renderers, with no React. sequence-ui is a three pane React editor: visit list, flowchart and a live document preview. The estimator stores a living plan plus immutable version snapshots, and one shared text module keeps the preview, Word and PDF from drifting apart.

Process

Generation picks a transcribed master that fits the estimate. A procedure with no matching visit prints as a yellow open item, an unsupported combination asks for a manual build, and a free text wait stops date projection instead of guessing. The packages reach the estimator as a committed build snapshot stamped with its source commit, and a check fails if core and ui come from different commits.

Result

Live inside the estimator since 27 August 2026, with save, versions and PDF in a second release that evening. A production audit on 27 August tried every scenario of every live estimate: 263 of 271 attempts matched a validated master, 8 opened empty for a manual build, and 0 errored.

Problem

The first version, in Apps Script, joined patients to leads by name. In a review on June 3, Buffalo's consults and case acceptances read zero. Every metric also had three implementations (card, drilldown and trend), so two tabs could disagree.

Solution

A rebuild on Cloud Run behind IAP. Cloud Scheduler checks Drive every five minutes; a private ingest service parses the four exports with ExcelJS, joins and hashes them, and rebuilds when all four files have changed. The browser loads one pinned snapshot of about 0.4 MB and computes everything locally with the same core package the ingest uses, and each card number is a function of its drilldown rows by construction. Every morning at six the same check reads the three patient boards from the Monday API for the Cash Flow tab.

Process

Business rules were ported verbatim and diffed against the original Apps Script code. When that parity check missed a one day date shift (both sides used the same Excel reader), a golden test pinned 948 dates read off the old production dashboard. A request sequence guard stops stale results from landing.

Result

Live on Cloud Run since 2 September 2026. The Weekly tab dropped from about 5.2 seconds to about 17 ms, ambiguous links fell from 31% to 5.8%, a Cash Flow tab shipped on 15 September and reads Monday every morning since 8 October, and on 28 October a request from the finance lead was live 19 minutes after it was filed.

Problem

A three person insurance team spent about 70 hours a week cross checking the schedule, the production ledger, and the clinical notes by hand to confirm every patient seen got documented and billed under the right doctor. It was slow and it failed exactly where mistakes cost the most: care documented but never billed, billed with no note behind it, or billed under the wrong provider.

Solution

A pure, deterministic reconciliation engine inside a thin FastAPI app. Two source adapters (Eaglesoft CSV, Denticon xlsx) turn hostile exports into the same typed models, the matcher keys everything on patient_id, and a stack of checks (money against the note, the billing provider against the doctor named in the note, the codes a note claims against the ledger, perio charting, office policy rules) separates verified patients from the few that need a human.

Process

The engine has no network, no database and no clock, and it takes the timestamp as a parameter, so identical inputs give byte identical output and every count traces to a source row. Columns map by name and a missing one stops the run with an error that names it. The app checks the dates inside every file and warns when an export covers the wrong day, after one Monday's notes export defaulted to the previous Friday and showed 85 patients billed with no note. Reviewers sent back every patient the tool got wrong, and each one was traced, fixed, tested and shipped.

Result

Live on Cloud Run. About 70 hours a week of manual cross checking became an exception review, over 3,600 hours a year.

Problem

The VP of Finance had built a sound forecast in a 14 tab Excel workbook and handed it over with a spec, but it needed a manual paste, recalculate and send every morning, fed by two daily export emails from the dental lab's case system.

Solution

A pure Python engine package with no I/O, and a pipeline package with parsers, a dedupe ledger and a BigQuery loader, with Terraform for the infrastructure. A Cloud Run job runs the model each weekday morning, and a Cloud Run web app behind IAP shows the dashboard, history and a Projections tab. An Apps Script bridge runs inside the VP's own Google account and copies the report attachments to a landing bucket, so the project never holds a credential that can read that mailbox. Gemini writes the commentary over finished numbers only.

Process

Parity first: every acceptance value and edge case from the spec is pinned in the test suite. Every number in the Gemini commentary must appear in the report payload, a list of banned phrases blocks advice the model has no business giving, and if the guard fails the report falls back to a deterministic template. No auto tuning: the best in sample parameter grid scored 2.59% but was 0.62 points worse out of sample. A better lag model sits behind a switch because its 0.28 point gain did not clear the noise floor.

Result

First scheduled report on 24 September 2026, 16 days after the first commit, built by 6:25 each weekday since, in about 49 seconds a run. Every weekday since the 7 October fix went out, 16 of 16 through 29 October. Current month revenue error falls from 4.2% early in the month to 1.5% late, and the report never depends on the LLM.

Problem

Our marketing numbers lived in five logins, and nothing joined an ad click to a booked patient.

Solution

Google Ads lands through the BigQuery Data Transfer Service; Microsoft Ads, Meta, CallRail, Monday, GA4, Search Console, Business Profile and TapClicks come in through Python connectors running as Cloud Run jobs on Cloud Scheduler. Data moves from raw to staging to marts, every column carries a description, and a data guide tells an LLM what to read first.

Process

A daily ops job checks freshness and drift, alerting on a z score above 3 against a 28 day baseline, and a weekly eval asks Gemini 22 golden questions. The lead to patient join moved from matching on contact details and the Google click ID to the link staff already keep in Monday, with the match method recorded on every row.

Result

Live since 4 August 2026. Ten sources are pulled at 6 AM, a 6:30 email with one tab per source goes to the marketing team every morning, and a Claude connector has answered questions from it since 23 October. The weekly eval scored 21 of 22 on 26 October.

Problem

Asking Claude about our marketing data took the Google Cloud SDK, two command line sign ins, a database tool, a hand edited Claude config and a fresh Google Cloud login most days. Every new person would repeat all of it.

Solution

A remote MCP server on Cloud Run. An owner page lists the people and 13 boxes, one per data source plus a few that unlock more detail, and each set of boxes gets its own BigQuery dataset of views. Claude writes SQL against the warehouse's own table names, and a guard points every table at that person's dataset before anything runs.

Process

Each question runs as one SELECT against the asker's own views, and Claude ends every answer with where the numbers came from. An accuracy layer that moves metric math to the server is built on main, with an eval that asks Claude 40 golden questions through the connector.

Result

Live since October 23. From October 23 to 29, three people made 480 tool calls on six days, 370 of them queries.

Problem

Denticon holds every chart and appointment at our three offices, and four services need what is in it. Its API has no patient search, so a copy of our own is the only patient index we have, and only one service should ever hold its credentials. The copy measured 6.0 days behind Denticon on September 21, because nothing ran the sync on a schedule.

Solution

A sync service: the CDF's own image deployed as a second Cloud Run service, holding the only Denticon credentials. Denticon posts a pointer when records change; the receiver saves it and answers inside Denticon's ten second window. A worker every ten minutes fetches each slice and upserts the rows into Firestore, a sweep at twenty past each hour lists any slice a webhook missed, and a 4 AM poll reads everything.

Process

Denticon ignores a query parameter it does not know and returns the whole table with a 200, so only filters proven to change totalCount are allowed. A freshness report starts from the cursors it expects, so a missing one shows as the worst status.

Result

Four services read the mirror and none holds a Denticon credential: the CDF's patient list, the estimator and the capacity planner through the registry, and the report renderer before it emails a patient.

Problem

On September 21 two apps needed Denticon's appointment book: the treatment estimator for a landing page of who is coming in today, and the capacity planner for the whole book every minute. Only the CDF may hold Denticon credentials.

Solution

A registry: five read only routes on the CDF dashboard service, over the Firestore mirror that the Denticon sync keeps fresh. The estimator gets one local day of the book; the planner gets the book by date window or by what changed, plus providers, visit types and chairs.

Process

Each caller has its own bearer secret, compared in constant time, and the registry never calls Denticon. Answers to the planner carry each office's mirror health, so it can show old data as old.

Result

Two apps read it: the estimator's landing page, the first screen every coordinator sees, and the capacity planner every minute.

Problem

Every intake survey needs a one page summary for the patient and a doctor report for the office.

Solution

A Fastify service on Cloud Run that renders each PDF in a fresh headless Chromium, stores it and delivers it. A survey submit becomes one named Cloud Task, staff on the CDF dashboard can regenerate a report, and an hourly sweep picks up anything unfinished.

Process

Each step is recorded as it lands, and every retry reads that record first. The clinic email waits until both reports exist.

Result

Every intake and experience survey from the three offices goes through it, and so does the CDF dashboard's Regenerate button.

Problem

By late October the list of Hybridge projects had reached 38. Staff needed one place to open any of them, four leaders wanted to see what is being built, and change requests arrived in chats and in passing, with no screenshot, no id and no record of what happened to them.

Solution

One page behind Google sign in. The Apps tab shows every project as a card in panes by status, the four leaders also get Work and History, and a Feature requests tab takes a pasted screenshot and a line. The same request screen lives inside six other apps, which all send to one relay.

Process

One editor changes the cards, and each save writes the project and a history entry with who, when and every field's old and new value. The relay is Launchpad's own image deployed a second time, so the board and the relay always run the same code.

Result

38 projects and 21 logged edits by October 29. The request counter reached FR-0006: four requests about three apps, two of them shipped.

Problem

Change requests for our apps arrived in chats and in passing. Launchpad sits behind IAP, and six apps on their own Google Cloud projects needed to file requests from their servers.

Solution

A relay: Launchpad's own image deployed a second time as its own Cloud Run service, with relay mode on and no IAP. Each app serves the same request screen and forwards every call from its own server with a Google ID token for its own account and the person its own sign in already checked.

Process

In relay mode the service answers only the request API and a health check, and Cloud Run lets in only the six app service accounts. Each app may file only about itself, and only Launchpad sets a status.

Result

Six apps file through it: the treatment estimator, the capacity planner, the CDF Patient Dashboard, Hybridge Forms, the Cowork Dashboard and the Doctor Portal. Requests land in Launchpad's Firestore and ping one Google Chat space.

Problem

Company knowledge sat in drives, decks and people's heads. A plain vector search misses exact terms, cannot settle two documents that disagree, and has no idea who may read what.

Solution

One Postgres on Cloud SQL holds vectors, the keyword index, permissions, versions and chats. Each question is searched by meaning with pgvector and by exact words with full text search, inside the asker's groups. The lists are fused, Vertex AI reranks them to 8 passages, conflict rules pick between documents, and Gemini 2.5 Flash answers with citations. Dropoff, the upload tab, hashes each file, skips duplicates, keeps the original in Cloud Storage and chunks it.

Process

Built in five stages, each with its own spec, plan and tests. The permission filter is a SQL condition inside both searches, so a restricted passage never becomes a candidate. A seeded retrieval test fails the build if recall at 8 drops below 0.8 or mean reciprocal rank below 0.35.

Result

It ran on Google Cloud from June 23, with company Google sign in, the Dropoff portal and cited answers streaming into a chat, and real models in production by July 16. Higher priority tools came first after July 23, and its billing has been off since October 8, 2026, so it is paused.

Problem

Some CBCT scans arrive unusable: the patient moved, metal threw streaks, or part of the jaw sat outside the field of view. Nobody knew until a designer opened the case and waited on a rescan. A vendor had quoted a six figure build and a monthly fee to run it.

Solution

An in house quality gate. The lab's case system exports each case to a small locked down SFTP box, which hands it to the validator on Cloud Run. The validator scores it with a frozen DentalSegmentator encoder and a small head, then sends the verdict back over SFTP.

Process

Six candidate models sat behind one interface by April 7. Model H's first 0.80 AUROC leaked: seven of the ten bad holdout studies had been in its training data, so I rebuilt the split and kept the honest 0.6309 on 44 test studies. The threshold is priced in rescans, with a missed bad scan counting 15 times a false flag.

Result

Deployed on Cloud Run since April 22 and on v0.6.1 since May 1, 37 days after the first commit. Our testing team checks studies in a review app: of the 30 they marked bad, the review app's model flagged 26. That model is separate from the validator's. It cost $62 on Google Cloud from October 1 to 28, measured.

Problem

Per seat SaaS automations were adding up, and executive analytics depended on manual weekly exports.

Solution

Self hosted n8n on AWS via Docker: one platform for every team automation, with standard data flows across teams.

Process

Moved existing automations into n8n, and built executive analytics pipelines that publish on a schedule.

Result

Team automations and executive analytics run on one shared, self hosted platform.

Problem

Doctors write the prescription in the lab vendor's customer portal, which cannot edit an existing case, so every prescription arrives as a second case that duplicates the scan case already in the system, and customer service has to catch each pair to merge it.

Solution

A Next.js app in the Hybridge design on Cloud Run behind IAP that lists the likely duplicates. The data sits behind a case source and store interface: sample data, with the vendor's API and Firestore planned.

Process

The name matcher forgives case, spacing, a middle initial, swapped first and last names, and a single mistyped letter. Anything more is a different person.

Result

Demo deployed on 30 September 2026 on sample data. The lab turned the approach down that day, and the Doctor Portal took its place, live on sample data since 28 October 2026.

Problem

Outside doctors send our lab work. A doctor scans the patient and the scanner opens a case in MagicTouch, the lab's case system. The doctor then writes the Rx in MagicTouch's own portal, which cannot edit a case that already exists, so the Rx opens a second case. In the lab lead's words, the doctors "see us cancel one and then they get freaked out."

Solution

A doctor portal built from the lab lead's own July mockup. The doctor sends the scan from the scanner, then adds the Rx to that same case here. A switch in the bar flips between the doctor's view and the lab's, which stands in for MagicTouch until a real link exists.

Process

It went from the sync that made it top priority to a working live link in 3.7 hours. Every release note ends with what is still pretend: sample data, files by name, payments and emails off, no doctor sign in.

Result

A live link on sample data since 28 October 2026, for the lab lead to review. Only Hybridge Google accounts can sign in. Real data waits on a vendor license and the lab server's details, and file uploads to Cloud Storage are next.

Problem

Hybridge has two public websites: the patient site, where someone weighing full arch implants first meets the practice, and the lab site for the dentists who send our lab their cases. The ask on October 28 was to recreate the patient site with better modern taste, more colour and better UX, then the lab site.

Solution

Two Astro sites on the Hybridge design system, each its own Cloud Run service. Every page is prerendered at build time. The patient site has a 3D full arch to turn and twelve patient stories that play in place; the lab site opens on an exploded full arch that assembles as you scroll.

Process

Pages were built by parallel page agents and read at 1440 and 390, and a marketing review cut the patient home page from 13.7 screens to 7.0.

Result

In build: both sites are previews on Cloud Run for the team to review, not yet on their public domains. The forms show what they would send, and the lab site already redirects 21 old addresses.

Problem

"Detect fake news" hides two jobs: is a claim true, and how does a crowd feel. They need different models and different data.

Solution

Llama 3 8B fine tuned with QLoRA on LIAR for True, False or Personal labels, zero shot Twitter RoBERTa for mood, LDA for topics, and Power BI state maps.

Process

Collapsed LIAR's six labels to two, removed tweets that appeared under both hashtags, and capped each answer at one token.

Result

76% on LIAR test claims, more than 156,000 tweets labeled per hashtag, state and swing state maps, and a nine theme topic table.

Problem

A class contest: the best CIFAR-10 classifier, with hard rules. Stay a ResNet, and stay under 5 million parameters.

Solution

With a bigger model off the table, we added data instead. AutoAugment, random crops, flips and perspective changes gave the model far more variety without adding a single parameter.

Process

Flip and crop alone topped out at 93.76%. Adding AutoAugment reached 95.34%, and adding perspective reached 97.12%. A cosine learning rate schedule beat a step schedule, 97.12% against 92%.

Result

97.12% on the 10,000 CIFAR-10 test images after 300 epochs, with 4,978,810 parameters, 21,190 under the cap.

Problem

Find the 100 most similar users among 330,975, judged by which movies they rated. Comparing every pair means about 55 billion comparisons.

Solution

MinHash with 30 permutations and an LSH index with 6 bands in datasketch, after Spark's MinHashLSH join kept losing nodes on Dataproc.

Process

Tried 15 to 500 permutations and 2 to 8 bands, kept the setting with the best top 100 correlation, and checked it against random pairs.

Result

0.7348 average rating correlation for the top 100 twins against 0.0323 for random pairs, in 37 seconds of indexing and querying.