Case studies · Selected engagements
Selected project work from LaunchPad Lab
LaunchPad Lab is a Chicago IT company specializing in web, mobile, software development, and AI solutions. The projects below are representative of the work we take on. We've left out client names where an agreement requires it, and we don't publish numbers we can't stand behind.
How to read these projects
The common thread is a specific bottleneck rather than a technology preference. In several cases the honest answer involved less software than the client expected, and in one we recommended configuring an existing tool instead of building. If your situation resembles any of these, the scoping conversation will be quick. If yours is different, that's useful too.
Problem first
Every write-up opens with the bottleneck, not the stack.
What shipped
Each entry ends with the delivered result and its limits.
A B2B portal
A B2B portal that replaced manual account setup
A services company was onboarding new business accounts through email threads and spreadsheets, with a sales rep manually provisioning access for each one. The work was mostly process mapping before any code: three teams touched onboarding, and their definitions of a complete account didn't match.
Approach
Process mapping with three teams, then a portal with self-service account creation, role-based permissions, and an admin view for exceptions.
What shipped
The portal shipped with the CRM integration so account data lived in one place instead of three inboxes.
Why it mattered
A sales rep stopped provisioning every account by hand, and one definition of a complete account replaced three.
Cross-platform mobile
A cross-platform mobile app for field teams
A field operations team was running inspections on paper forms and re-entering them at the office. The app we built runs on iOS and Android from a shared codebase, works offline in areas without signal, and syncs when the device reconnects.
Offline behavior drove the architecture: local storage, conflict handling on sync, and clear indicators when data hadn't uploaded. Native was unnecessary here because the feature set didn't depend on device hardware beyond the camera.
Approach
One shared codebase for both platforms, with the sync layer written first because offline behavior decided everything else.
What shipped
Inspection capture on the device, an upload state the crew can read at a glance, and a sync queue that survives a lost afternoon of signal.
Internal systems
An internal tool that retired a spreadsheet
fourteen tabs, one person who understood them
The starting point
a web application with validation and history
What we built
an API so other systems could read the schedule
What shipped
the team can change the process itself
Why it mattered
The value wasn't the interface, it was removing the single point of failure. Their team could now change the process without waiting on the one person who knew the formulas.
AI in a regulated process
AI document review for a compliance workflow
A compliance team was reading vendor contracts by hand to pull out renewal dates, liability terms, and unusual clauses. We built a retrieval-backed review tool that surfaces the relevant passages with citations, plus an evaluation set of contracts with known answers so quality could be measured on every change.
Reviewers confirm every extracted field before it's saved. That confirmation step is what made the tool usable in a regulated process.
What the tool does
Answers arrive with the passage they came from, so a reviewer checks the source instead of trusting a summary.
Why it stayed in use
Nothing is saved until a person confirms it, which is the part a compliance process actually requires.
A rebuild, not a rewrite
A web platform rebuilt for growth
A product that started as a prototype had reached the point where every new feature broke something else. Rather than a full rewrite, we rebuilt the data layer and API, moved background jobs off the request cycle, and introduced staging and automated tests.
The front end stayed in place with targeted changes. Rewrites are expensive and often unnecessary; sequencing the work by risk usually gets a better result.
Rebuilt the data layer and API
First
Moved background jobs off the request cycle
Then
Introduced staging and automated tests
Alongside
Targeted front-end changes, not a rebuild
Last
Search over a knowledge base
Search that answers with cited passages
A support organization had years of documentation spread across a wiki, PDFs, and old tickets. We built a search experience that answers questions with cited passages from those sources rather than a generic model response. Most of the effort went into chunking documents sensibly and keeping the index current as the wiki changed. Long-context processing was evaluated for the document-heavy queries before the final model choice.
Sources
A wiki, a folder of PDFs, and years of closed tickets, indexed as one body of material.
Where the effort went
Chunking documents sensibly, and keeping the index current as the wiki changed underneath it.
Model choice
Long-context processing was evaluated for the document-heavy queries before the final choice was made.
What shipped
Answers that carry their sources, so a support agent can hand a customer the actual passage.
Integration work
An API integration layer between six systems
A company had six tools that each worked fine and didn't talk to each other. We built an integration layer with retry logic, error reporting, and a reconciliation view so failed syncs were visible instead of silent.
The project wasn't glamorous. It removed hours of daily manual re-entry, which was the entire point.
What the layer handles
- Retry logic on every transfer, so a dropped connection doesn't become a lost record.
- Error reporting that names the failing pair of systems instead of the whole pipeline.
- A reconciliation view so someone can see what didn't sync and fix it the same day.
Questions these projects usually raise
If a project shape below looks like yours, the scoping conversation can start from the same questions. Expand each one to see how we answer it.
Do you always build custom software, or do you recommend configuring something that already exists?
Both happen. On the scheduling project we rebuilt a spreadsheet as a web application because the process was the bottleneck. In one other case we recommended configuring an existing tool instead of building, and we said so in writing. The work starts with the process, not with a preference for custom code.
Why don't the case studies include client names or results numbers?
Some agreements don't allow naming the client, so we describe the shape of the project instead. We also skip numbers we can't stand behind. If a measurement was never set up before the work started, publishing an after-the-fact figure would be guesswork, and we'd rather leave it out than dress it up.
How do you decide between a native app and one codebase for iOS and Android?
It depends on whether the features need device hardware. The field team's inspection app used the camera and offline storage, and nothing else was hardware-specific, so one shared codebase was the right call. When a feature genuinely depends on a platform capability, that answer changes.
What does an AI feature look like when the process is regulated?
The document review tool surfaces passages with citations and a reviewer confirms every extracted field before it's saved. Nothing enters the record unconfirmed. The evaluation set of contracts with known answers lets the team re-measure quality on every change rather than trusting a first impression.
What do you need from us before scoping starts?
A description of the bottleneck and who it affects. If three teams touch the process, it helps to know that on the first call. You don't need a specification or a stack decision before we talk — the process map usually comes before either of those, and that's the part we can do together.
Where we are
448 N La Salle Dr Fl 9, Chicago, IL 60654, United States
When we're in
Monday–Friday, 9:00 AM – 6:00 PM
Reach us
Contact LaunchPad Lab at [email protected] or +1 415-526-3479.