nadwell.ai

Work

Six examples of what we build.

Each example below is illustrative. The businesses are fictional Colorado companies, and the timelines show how a project of that size typically runs. They are not results from past clients.

Illustrative exampleMobile app

Summit Peak Plumbing & Heating

Colorado Springs, COExample timeline: 8 weeks

Example plan: 22 pieces, 3 milestones

The problem

Twelve technicians worked from paper tickets and phone calls. Parts used on a job were often never billed, and the office could not see who was where.

What we built

An iPhone and Android app for technicians with today's jobs, customer history, photos, parts used and on-site signatures. It works offline in basements and syncs when signal returns. The office gets a web dispatch board.

Process highlights

  • Mocks tested on the techs' own phones in week one
  • Offline sync built as its own piece and tested with the network cut
  • Test builds on the team's phones after every piece

Tech

React NativeNode.js APIPostgreSQLOffline syncAWS
Illustrative exampleWeb app

Mile High Bakery Co.

Denver, COExample timeline: 6 weeks

Example plan: 26 pieces, 4 milestones

The problem

About forty cafés ordered bread by text and voicemail. Orders arrived after the bakers' cut-off, and invoices were typed up by hand every Friday.

What we built

A wholesale ordering portal: each café has an account with its own prices, standing weekly orders, cut-off times per delivery zone and invoice PDFs. Bakers get a printable production sheet for each morning.

Process highlights

  • Cafés tried the clickable mock before any code
  • Standing orders shipped first, so the bakery used the portal from week three
  • Every piece tested in Chrome, Safari and Firefox

Tech

ReactNode.jsPostgreSQLStripe invoicingPDF generation
Illustrative exampleDesktop app

Front Range Dental Lab

Lakewood, COExample timeline: 7 weeks

Example plan: 19 pieces, 3 milestones

The problem

Crown and denture cases were tracked on a whiteboard and in a shared spreadsheet that kept getting overwritten. Rush cases were missed.

What we built

A Windows app for the lab bench: scan a case barcode, see the prescription and due date, move it through each station, and print labels. A daily board shows rush cases first.

Process highlights

  • Barcode scanning tested with the lab's real scanners
  • Automated clicks on a real Windows desktop for every screen
  • Signed installer with release notes for each version

Tech

.NET 8Windows desktopSQL ServerBarcode labelsSigned installer
Illustrative exampleData migration

Cottonwood Property Group

Fort Collins, COExample timeline: 5 weeks

Example plan: 14 pieces, 2 milestones

The problem

Leases, tenants and maintenance requests for 300 units lived in an old Access database and a dozen spreadsheets that disagreed with each other.

What we built

A cloud database with one clean record per unit, lease and tenant, plus the monthly reports the owners actually read. The old files stay read-only as an archive.

Process highlights

  • A field-by-field map agreed before any data moved
  • Two rehearsal runs in the preview, reconciled to the penny
  • Cut-over over one weekend with a rollback plan

Tech

PostgreSQLAWS RDSPython ETLReconciliation reports
Illustrative exampleEnvironment build-out

Switchback Freight

Commerce City, COExample timeline: 4 weeks

Example plan: 11 pieces, 2 milestones

The problem

The whole product ran on one virtual machine. Deploys were done by hand over SSH, there was no staging, and nobody had tested a restore.

What we built

Dev, staging and production environments defined as code, with automated deploys on every merge, nightly backups, a tested restore, and one-click rollback.

Process highlights

  • Environment diagram approved before any change
  • Restore and rollback drills had to pass before production moved
  • A written runbook for the team

Tech

TerraformGitHub ActionsDockerAWSBackups
Illustrative exampleScaling

Powder Day Rentals

Breckenridge, COExample timeline: 5 weeks

Example plan: 12 pieces, 2 milestones

The problem

The ski-rental booking app slowed to a crawl on Saturday mornings and on the first big snow of the season, exactly when bookings mattered most.

What we built

Load tests that copy a peak Saturday, caching for availability lookups, a queue for confirmation emails, database tuning and autoscaling ahead of the season.

Process highlights

  • Load tests written first, so every fix could be measured
  • Each fix shipped as its own piece and retested under load
  • A peak-day runbook handed to the shop's manager

Tech

Load testingRedis cacheJob queuePostgreSQL tuningAutoscaling

All examples on this page are illustrative. Company names, people and timelines are invented. No testimonials or metrics shown here come from real clients.