Airtable Feedback Base Rebuild for a Review Platform
Rebuilt an Airtable feedback base in place, preserving data while fixing its schema, AI Summary field, and public intake form.
Read the projectPlatform modernization
Modernize the platform. Keep the business moving.
Replace the parts that slow your team down through a staged migration. Plan data movement, compatibility and rollback around the operations that must keep running.
- 20–30 minute review
- No preparation needed
- Migration path mapped
Migration · Slice 4/6Downtime: 0
Legacy
core v1 · 2011
Custom scripts
Reports
still serving traffic
Target state
Auth ✓
Billing ✓
Accounts ✓
Orders ✓
dual-run parity 100% ✓
Migrated: 3/6Cutover: reversibleContinuity: 100%
Illustrative workflow · Sample figures, not projected results
A scoped project or ongoing support—choose after review.Engineering Capacity
Organizations we’ve worked with
- Airbnb
- TheAMLab
- Hood
- NAMA
- Klaro
- GoBoon
- Studio Arlington
Where the platform holds you back
The signs your platform has outgrown its design
None of these mean the original build was wrong. They mean the business moved on, and the platform did not.
The diagnosis
All six are one problem: the platform outlived its design — continuity now depends on not touching it. Make change safe again, and the rest of the list starts disappearing with it.
- 01The system nobody dares touchOne module — written years ago, by someone long gone — that everyone routes around and nobody will open.
- 02Vendor and version lockStuck on an end-of-life framework or database version because upgrading breaks things nobody can predict.
- 03Data trapped in silosThe numbers the business needs exist — inside a schema only the legacy system can read.
- 04Every change risks the businessA one-line fix needs a week of testing, because nobody knows what else it touches.
- 05Hiring for dead techThe stack narrows the hiring pool every year, and the people who still know it are leaving.
- 06Integrations held by duct tapeCSV drops, nightly jobs, and hand-rolled scripts stitch systems together — until one silently fails.
Safe migration path
Legacy to modern, without the big bang
The platform migrates one slice at a time behind stable interfaces. Old and new run side by side with behavior compared live, so the business keeps running while the architecture changes underneath it — and every step stays reversible.
99.95% uptime
CI/CD, infrastructure, and monitoring rebuilt for safe releases across a multi-app healthcare platform — with 96% faster release cycles after the migration.
The honest boundary
We do not big-bang rewrite. The all-at-once rebuild is the version of modernization that fails — scope balloons, the legacy system drifts, and the plan gets shelved. We move in slices, dual-run old and new, and keep every cutover reversible.
- One slice at a time, chosen by risk and business value
- Old and new run side by side until parity is proven
- Cutover stays reversible — rollback is one switch away
ILLUSTRATIVE WALKTHROUGH
Move one migration slice at a time
- 01
Define · a stable boundary
Select one workflow and document its data, consumers and compatibility requirements.
- 02
Compare · old and new
Validate representative records and behaviour before moving the agreed traffic.
- 03
Cut over · keep a recovery path
Use an approved cutover plan, monitor the result and retire the old path only after acceptance.
Any downtime window, rollback limitation or accepted data risk is agreed before the migration.
PUBLISHED PROJECTSee the work
See the work
behind the approach.
Related in-place data and workflow improvement. A broader legacy-platform migration has its own assessment and scope.
Pick a scenario
The same change, on a platform that can move
Pick the one that sounds familiar — today on the left, mid-migration on the right. A representative pattern; your map will be exact.
Today — on the legacy platform
- 1The estimate starts at “it depends”unknowable
- 2The change touches the module nobody knowsfear
- 3Testing means clicking through the whole appa week of QA
- 4Release waits for the quarterly windowmonths out
- 5A regression surfaces somewhere unrelatedrollback
Months to ship · whole-app risk
With the migration underway
- The feature lands in the extracted sliceisolated
- A stable interface bounds the blast radiuscontained
- Automated tests cover the seamverified
- Shipped when ready, not on the quarteron demand
- Legacy untouched, business uninterruptedsafe
Days to ship · risk bounded to the slice
Works with the stack you already run
The target state is built on tools your team can hire for.+ your existing infrastructure
- AWS
- Azure
- GCP
- Kubernetes
- Docker
- Terraform
- GitHub Actions
- Grafana
- Prometheus
- Sentry
- Cloudflare
- Postgres
How it works
The capabilities that deliver it
Platform Modernization is built from three engineering capabilities working together.
Primary
Reliability Engineering
A safe migration path with observability, incremental delivery, and rollback so modernization never risks production.
Safe migrationObservabilityRollback
Explore capabilitySupportingIntegration
Stable, well-defined interfaces so systems connect cleanly and old and new can run side by side during migration.
Stable interfacesDual-runningData sync
Explore capabilitySupportingProduct Engineering
Re-shaping the platform around how the business actually works today, not the assumptions it launched with.
Target architectureRe-shaped domainsMaintainability
Explore capabilityDo the math
How much drag is the legacy platform adding?
Slide to your reality. This is only arithmetic — the assessment tells you which of that drag the first slice would actually remove.
125
120
Legacy drag
30hrs/week
≈ 1,380 hours a year spent on workarounds, manual exports, and change-fear overhead instead of moving the business forward.
Planning estimate based on the inputs above, not a forecast of savings.
Assumes ~46 working weeks a year. We will tell you which of that drag the first slice removes — and when the platform is actually fine as it is.
How we deliver
From frozen platform to reversible migration
Four phases, and each one hands you a concrete artifact — not a status update.
- 01 · Map
Map the estate
We chart the legacy architecture — dependencies, data flows, and where change is genuinely dangerous versus merely feared.
You get
A dependency map with the first slice chosen
Done when
The first slice and its seams are named
- 02 · Slice
Carve the first slice
We define a stable interface around one high-value slice and rebuild it on the target stack behind that seam.
You get
The slice rebuilt on the target stack, behind a stable interface
Done when
The slice runs on the target state with parity verified
- 03 · Migrate
Dual-run and move traffic
Old and new run side by side while traffic shifts gradually — behavior compared live, rollback one switch away.
You get
Old and new running side by side, compared live
Done when
The new path carries real traffic with rollback intact
- 04 · Cut over
Retire the legacy path
Cutover happens slice by slice and stays reversible until the end — then the legacy path is switched off for good.
You get
A reversible cutover executed slice by slice
Done when
The legacy path is retired after agreed validation and approval
Is this the right starting point?
Where Platform Modernization fits
We would rather tell you the platform is fine than sell you a migration you do not need.
Good fit when
Start here- A legacy platform the business depends on every day
- Changes are slow and risky, and every migration feels like it could take production down
- Continuity during migration is essential — the system cannot go dark
- Brittle integrations and tech debt now set the pace of every change
Not a fit when
Not yet- A greenfield build with no legacy platform to migrate from
- A simple dependency bump or version upgrade is enough
- There is no appetite for a phased, incremental migration
- The real constraint is product direction, not the underlying platform
Not sure which side you are on? Most teams aren’t — until the workflow is mapped.
YOUR FIRST ENGAGEMENT
Start with one boundary you can modernize safely.
Choose a costly change, fragile dependency or unsupported component. Define a migration slice that can be verified before the next one begins.
Start with a conversation
Bring the current system map, a difficult recent change and the operational constraints you need to protect.
An example helps; a finished specification is not required.
BEFORE IMPLEMENTATION
Know what you are agreeing to.
- A dependency and migration-boundary assessment
- Data validation, compatibility and rollback criteria
- A phased scope with checkpoints and ownership
We agree the scope, delivery approach and price before implementation. Where discovery is needed, its scope and fee are agreed first.
Continuity is planned and tested. Any cutover window, compatibility constraint or accepted risk is agreed before migration.
BEFORE YOU GET STARTED
Platform modernization questions
Scope, delivery and what happens next. The details that help you decide.
A RELEVANT WAY TO WORK WITH US
Engineering Capacity
Add engineering support to an existing roadmap, with responsibilities and delivery expectations agreed before starting.
Explore Engineering CapacityAsk about your projectDo you recommend a full rewrite?
Not by default. We assess the constraint and look for a migration boundary that can be delivered and checked in stages. A larger rebuild is considered when the existing design prevents the required outcome.
Can you guarantee no downtime?
No blanket guarantee is appropriate before reviewing the system. We agree compatibility checks, data validation, cutover windows and recovery limitations for each migration stage.
How does Engineering Capacity fit a migration?
Capacity can support an ongoing modernization roadmap led by your team. A defined migration phase may instead suit a scoped project. The first discussion establishes ownership, boundaries and the appropriate commercial arrangement.
What happens before implementation starts?
We review the intended outcome, existing systems and dependencies, then agree deliverables, acceptance checks, responsibilities and price. If discovery is needed first, its scope and fee are agreed separately before that work begins.
How long will the work take?
The delivery plan depends on scope, access, integrations and review dependencies. We agree milestones after that assessment rather than promise the same timeline for every system.
What access or preparation do you need?
Bring an example of the workflow or user journey and an overview of the systems involved. We agree the access needed for the work. Do not send passwords or private customer data through the enquiry form.
What happens after handover?
Handover, documentation, defect coverage and any ongoing support follow the chosen offer and written scope. New features, additional integrations and continuing maintenance are not assumed to be included.
Start here
Start with the constraint holding you back
We will assess the platform, find the real constraint, and show you a safe first increment to modernize before the full journey.
20–30 minutes · No preparation needed · Not ready for a call? Send a note instead