Manufacturing OS on AIP

Turn spreadsheets into a real-time manufacturing MES. Connect machines, track work orders & quality — on Amazon Aurora PostgreSQL + Vercel. Built to ship and scale from day one.

Comment

Inspiration

Walk into a typical small-or-mid-size factory and you'll find the nervous system of the operation living in a spreadsheet. Machine setpoints are copied by hand off a controller, "today's plan" is a tab someone emails at 7 a.m., and the PLCs that actually run the floor are islands — disconnected, unread, invisible the moment you step away from the panel. When a job runs late or a batch goes bad, nobody knows until the customer calls. The people on that floor are skilled and serious, but they're flying blind, and the cost lands on real shifts, real margins, real jobs.

We built LINKO because that pain is concrete and almost entirely unsolved for SMBs. Enterprise MES platforms exist, but they assume an IT department and a six-figure rollout. The factories that need visibility most are the ones still typing it into Excel. We wanted to give them a real-time manufacturing system that connects their machines and shows the gap between plan and reality — on a data foundation that scales for real from day one, not a toy that buckles the first time a second shift logs in.

What it does

LINKO is a multi-tenant manufacturing MES (Manufacturing Execution System) SaaS, live at https://linko.sale. What sets it apart from a typical hackathon entry is domain depth that reaches all the way down to the machine-tool wire protocols:

  • Real machine-tool connectors — FANUC FOCAS2, MAZAK MTConnect, and Siemens OPC UA (actual protocol selection, not mocks). A guided wizard walks a shop from industry → company → equipment → live connection with IP/port and a connection test.
  • VizGap analytics, SPC, OEE, and work orders — visualization-gap analytics that surface where actual production diverges from plan, plus statistical process control for quality.
  • A real product, not a demo — payments via Toss Payments / Stripe / PayPal (webhook idempotency + HMAC), Popbill e-tax invoicing, and 15-language i18n including RTL.

A reviewer signs in to a populated MES dashboard: OEE 83.3%, on-time delivery 90.0%, defect rate 0.7%, across 6 machines, 10 work orders, and 10 inventory items.

How we built it

The hackathon story is a migration, not a greenfield build — and that's the point. LINKO was already serving live traffic on Amazon RDS PostgreSQL 16.6 (db.t4g.small, ap-northeast-2). For this submission we moved the live production database onto Amazon Aurora PostgreSQL Serverless v2 with zero application code changes.

That's possible because of disciplined choices made long before the migration. The stack is Next.js 16 (App Router) on Vercel over Prisma with provider="postgresql" and no RDS-specific extensions, so Aurora was wire-compatible — a drop-in. Every database coordinate already lived in environment variables, never hardcoded. So a database migration became a config change.

The cutover, completed June 5, 2026, was deliberately non-destructive. We provisioned cluster linko-aurora-pg (aurora-postgresql, --manage-master-user-password, --storage-encrypted, Serverless v2 0.5–2.0 ACU) reusing the existing VPC, subnet group, and security group — so Vercel egress and our Lightsail BFF reached the new cluster with no network changes. Provisioning took roughly 8 minutes; the cluster came up on engine version 16.6 and AWS subsequently auto-patched it to 16.11.4. Schema and data moved two ways, both clean: prisma migrate deploy replayed every migration in order (each _prisma_migrations row got finished_at — no failed-migration residue), and pg_dump --no-owner --no-acl | psql produced a 1:1 clone. 86 tables and 428 indexes transferred verbatim — no schema edits, no SQL rewrites, no app diff. Cutover was three Vercel env vars — DATABASE_URL (pooled runtime), DIRECT_URL (migration engine, direct TCP), TENANT_DATABASE_URL — then a redeploy: about 90 seconds, no PR.

We verified four ways: /api/health returned database: ok; pg_stat_activity showed Vercel egress IPs committing real transactions; SELECT aurora_version() returned 16.11.4 (a function that exists only on Aurora — proof it's Aurora, not vanilla RDS); and headless Playwright drove signup → onboarding → dashboard with zero console errors. The old RDS instance was never touched — kept warm as instant rollback, original strings saved to /tmp/h0-rds-rollback.env.

To be precise for the database experts judging this: the production core SaaS database — authentication, customers, admins, subscriptions, licenses, billing, and audit logs — runs on Aurora. That's exactly what a reviewer login and the trial/license check hit. The tenant dashboard's realtime operational metrics (OEE, work-order rows) are served from a separate per-tenant operational store, not from Aurora. Honesty matters here, especially to this room. We won't blur that line.

Challenges we ran into

The best war story: the Aurora master credential is managed by AWS Secrets Manager, and an automatic 7-day rotation drifted from the static Vercel env var around June 13, briefly breaking DB auth. We diagnosed it from a /api/health 503, fixed it, then disabled rotation (RotationEnabled: false) so the static env stays valid through the entire judging window — no down-time risk across June 30 to July 24. We also defended eligibility (LINKO predated the period, so we proved every Aurora/infra change landed after May 27 with a commit-hash evidence table) and split runtime vs. migration connection pools so schema changes never compete with request traffic. And we fixed first-render locale negotiation that was cutting English-browser LCP from 4.5s to under 0.2s.

Accomplishments that we're proud of

A live B2B product migrated to Aurora with zero code changes and about 90 seconds of cutover. And the numbers are real production traffic, measured live: 650,000+ committed transactions (a live, climbing counter), 86 tables, 428 indexes, a health_checks table with 24,449 rows. A 7-day CloudWatch read shows Aurora idling at the 0.5-ACU floor (hourly avg 0.503) yet bursting upward in 90 of 142 hours — pinning the 2.0-ACU ceiling for 36 of them — with connections averaging 3.2 (peak 7.3) and CPU at 23.7%. That's provisioned-DB behavior under load at near-zero cost at rest (about $43/mo at the floor, covered by AWS credits). Storage is SSE-KMS encrypted with a customer-managed key, PITR is on, credentials live only in Secrets Manager, and the subnet group spans three AZs.

What we learned

PostgreSQL wire compatibility is real — not one line of app code, one Prisma migration, or one SQL query changed. Prisma's migration engine is Aurora-safe end to end. And the most underrated lesson: keeping every DB coordinate in environment variables (never hardcoded) turned a database migration into a pure config change. Not clever engineering — just hygiene that pays off the moment you need to move fast. The cheapest insurance we bought was not deleting the database we migrated from.

What's next for LINKO

At 10x traffic we'll put RDS Proxy in front of the writer — a config change, not a rewrite. We'll promote the provisioned reader endpoint into a live Multi-AZ replica (so failover is an add-a-reader operation, not a re-architecture), expand row-level security across more tenant tables (row-level security already shipped to the Aurora-backed DB), and deepen the connector library beyond FANUC/MAZAK/Siemens. The foundation is built to ship and scale from day one — because it already is.

Live demo: https://linko.sale — reviewer login reviewer-h0@linko.sale / H0-Review-2026!.

Built With

  • amazon-aurora-postgresql
  • aws-secrets-manager
  • aws-ssm-parameter-store
  • fanuc-focas2
  • mazak-mtconnect
  • next-intl
  • next.js
  • nextauth.js
  • paddle
  • paypal
  • pinecone
  • popbill
  • postgresql
  • prisma
  • react
  • react-hook-form
  • recharts
  • sentry
  • siemens-opc-ua
  • stripe
  • supabase
  • tailwind-css
  • three.js
  • toss-payments
  • typescript
  • vercel
  • webauthn
  • zod
Share this project:

Updates