ATS

Selected work

Systems in the field

Seven systems, told the way we build them: the operational reality, the architecture, the decisions that mattered, and what the numbers actually measure. Six link to full case studies with the system diagram and the honest parts. Client work is anonymized where agreements require it.

01

From thousands of raw government tenders to a personal bid desk

Client:
TenderPulse, an ATS product
Industry:
Procurement intelligence
Status:
Live product

Indian government tenders are scattered across portals that were never designed to be read by machines: CAPTCHAs, session walls, inconsistent document formats. TenderPulse ingests more than 35 of them on a daily schedule through purpose-built scraping infrastructure, normalizes everything into one governed data layer, and turns each tender into a decision-ready briefing.

The AI layer is deliberately disciplined. Each tender gets one LLM-generated briefing, cached permanently, so costs stay flat as the corpus grows. The relevance engine only scores criteria a user actually configured, and returns nothing rather than a fake number when it lacks signal. Every match explains itself. The bid desk is now a team workspace, with seat-capped invites and named bid profiles that let one firm run several strategies against the same feed.

Stack: Python · PostgreSQL · Node.js · React · Gemini · Google Cloud Run

Read the full case study

By the numbers

35+
government portals monitored daily
80k+
tenders ingested into the governed data layer
1
LLM briefing per tender, generated once and cached
02

A recruiting operation run from Telegram, with AI that never acts alone

Client:
A premium spirits brand
Industry:
Recruiting operations
Status:
In production

A national brand hires field ambassadors continuously across as many as eight job portals. We built them a recruiting operations system their lean team runs entirely from Telegram: a deterministic fourteen-status candidate pipeline as the source of truth, with an AI coordinator that scores, drafts, and summarizes on top of it.

The architecture rule is strict: AI never takes an unrecallable action alone. Every job post, every group-call advance, every hire passes a human approval gate in Telegram; routine invite emails run on rails the team defined. Model routing and prompt caching keep the agent affordable enough to run all day.

Stack: Python · Claude · Google Sheets · Apps Script · Playwright · Railway

Read the full case study

By the numbers

14
statuses in the candidate state machine, the source of truth
8
job portals automated over the engagement
100%
of job posts and hires pass human approval
03

The client ran on spreadsheets. We kept it that way, and made it an operating system

Client:
A national beverage brand
Industry:
Field operations
Status:
In production

Field marketing for a national brand ran on Google Sheets and AppSheet, and the operations team knew every tab of it. Instead of forcing a migration, we wrapped that reality in an engineered platform: a mobile app for ambassadors, an admin scheduling console, and a Cloud Run API that treats Sheets as a real database, with per-tab locking, idempotency-aware retries, and audit logging.

Shift scheduling is a deterministic scoring engine across six documented signals. The AI explains the schedule; it does not decide it. If the model times out, scheduling continues without it. The platform runs the operation daily: the Android app is live on Google Play, iOS is in App Review, and a public application page feeds new ambassadors into the same admin approval flow.

Stack: Flutter · TypeScript · Google Cloud Run · Google Sheets · Claude

Read the full case study

By the numbers

3
surfaces: mobile app, admin console, API
6
signals in the deterministic scheduling engine
0
migrations forced on the operations team
04

Past the no-code ceiling: a validated AppSheet app rebuilt as a real platform

Client:
A cooperative fundraising organization
Industry:
Nonprofit operations
Status:
In development

Years of validated fundraising logic lived inside a production AppSheet app that had hit its ceiling. Before writing code, we extracted the business rules into specifications: architecture decision records, per-module specs, and a gap analysis produced by auditing the original app against its own user manuals.

The rebuild is a multi-tenant platform where tenancy is enforced in the backend on every request, permissions live in one matrix consulted by one service, and the fundraising workflow runs inside real database transactions. The specs are the source of truth; the code is generated from them and audited against them, with an integration test pack running against a real database in CI on every push.

Stack: NestJS · PostgreSQL · Drizzle · Next.js · TypeScript

Read the full case study

By the numbers

27
tables in the multi-tenant schema
19
architecture decision records before build
155
API endpoints across 26 modules
05

From six city portals to a quarter-million contract records

Client:
Contract Pulse, an ATS product
Industry:
Public-sector sales intelligence
Status:
In development

Awarded-contract data in the US sits in fragmented city, county, state, and school-district portals. Contract Pulse ingests more than 160 of them through a tiered pipeline: free structured APIs where they exist, cached extraction recipes where they do not, and an LLM-driven crawler only as the last resort. Cost discipline is the architecture.

Extraction runs on a fast model first and escalates to a stronger one only when confidence drops below threshold. Every AI-extracted field carries its confidence score, the quoted source evidence, and the model that produced it. Provenance is a feature, not an afterthought. The whole source fleet now refreshes on a weekly schedule, unattended.

Stack: Python · PostgreSQL · Gemini · Claude · React · Google Cloud Run

Read the full case study

By the numbers

160+
live sources normalized into one pipeline
2-tier
model escalation gated on extraction confidence
240k+
contract records normalized and served
06

Industrial-grade ingestion from hostile sources

Client:
ATS infrastructure
Industry:
Data engineering
Status:
Operating daily

Government portals fight automation: CAPTCHAs, fragile sessions, unannounced layout changes. The ingestion layer behind TenderPulse treats that hostility as a design constraint. One canonical scraping engine drives 37 portals through thin configuration shims; an orchestrator isolates every source in its own process with time budgets and clean escalation.

The details are where reliability lives: a SQLite write-ahead-log job queue that replaced a corruption-prone JSON file, workers that drain their queue instead of dying mid-upload, checkpoint and resume on every long scrape, and defenses against zip bombs in downloaded documents.

Stack: Python · PostgreSQL · SQLite · Google Cloud Storage · systemd

Read the full case study

By the numbers

1
canonical engine driving 37 portals via shims
5,500+
new tenders ingested in one fleet run
0
data lost since the queue rebuild
07

An offline-first inspection platform for mining equipment and rail freight fleets

Client:
A structural inspection company serving mining and rail freight
Industry:
Structural inspection
Status:
In development

The client inspects heavy assets for a living: mining equipment in service and an 800-plus wagon rail freight fleet, all run from two AppSheet apps on Google Sheets, nearly a hundred tables deep and past the ceiling no-code can hold. We are rebuilding that operation as one platform: offline-first field apps for inspectors, a web control room for the office, and a shared Postgres backend with one schema per product and row-level security.

Inspectors drop defect pins on the asset's own engineering drawings, offline, with photos and structured crack data; a durable event log syncs when connectivity returns, and every defect is tracked across successive inspections through a five-state lifecycle. Publishing runs a guided checklist and generates the PDF report on the device. The platform went from legacy-system analysis to a working, backend-wired build in about two weeks.

Stack: Flutter · Dart · Supabase · PostgreSQL · Python

By the numbers

3
app surfaces: two field apps, one web control room
550+
automated tests across the platform monorepo
96
tables in the no-code system it replaces

Have a system like these in mind?

Bring the operational problem. We will map the architecture with you in a focused thirty-minute session.

Book a Systems Strategy Session