Improve an existing product
Fix what's broken.
Keep what works.
Most products that feel broken don't need a rewrite. ezCater's site went from a 43 mobile Lighthouse score to 88. Bose's Home Speaker 500 trial campaign had been in development for 18 months when we arrived; it shipped two weeks ahead of schedule on the codebase they already had. Calibrate's progress screen was redesigned, tested with members, and handed to engineering in about four weeks.
Tell us what's not working, and don't hold back. You'll have a plan and a rough budget back within two business days.
What's not working?
Five things we hear most, and what we did about each one for a client whose case study is published.
The site got slow and nobody knows why
We profile it before we touch it. On ezCater's site, the main thread was busy with JavaScript doing work CSS could do, images were missing width and height attributes, and Google Maps and a chat widget loaded before anyone had interacted with the page. Fixing those took the mobile Lighthouse score from 43 to 88.
The project has been almost done for over a year
Bose's Home Speaker 500 trial campaign had been in development for 18 months. Our audit found UX side effects and security vulnerabilities, and we weighed a port to React. We kept the codebase instead, fixed the high priority bugs, and delivered two weeks ahead of schedule.
Users reach the screen and then don't do the thing
A screen can look finished and still fail its one job. Calibrate's progress screen graphed weight in pounds and gave members nothing to measure against their 10% goal. We prototyped a fix, tested it with Calibrate's own members over Zoom, A/B tested a second version, and handed a documented feature set to engineering in about four weeks.
Payments work today and we're not sure they'll survive the launch
PlayOn! Sports processes over 300 transactions per second on Friday nights and was moving from Stripe's legacy Charges API to Payment Intents ahead of a launch. Our certified Stripe architects spent two weeks in their front-end and back-end code, checked PCI compliance and peak-load behavior, and reported what was sound and what to change.
One feature is tangled into everything else
Brilliant for Educators lived inside Brilliant's core platform, spread across Vue 2 and Next.js code. We gave it a Next.js application of its own and lifted over the parts it needed; the brief was to do that without disrupting what was already working. Version 2.0 launched on schedule for the new school year.
Tell us what's not working, and don't hold back. You'll have a plan and a rough budget back within two business days.
Tell us what's not working
All of it, and don't hold back. Within two business days you get a plan for what we'd fix first and a rough budget for doing it.
An audit by the people who'll do the work
Before anything changes, the engineers who will ship the fix read the code. Bose's initial audit discovered UX side effects and security vulnerabilities. PlayOn's took two weeks and covered their Stripe front end, back end, and webhook handlers. You get what's sound, what's broken, and the order to fix it in.
Fix it, then ship it on the date
Sometimes the answer is keep what you have and fix the priority bugs; that's what got Bose to launch two weeks early. Sometimes it's a new application that lifts the working parts out of the old one, as with Brilliant for Educators. Either way there's a date, and the work above is what shipping on it looks like.
What you have at the end
The fix in production and the findings in writing. PlayOn got a final report with actionable recommendations. Calibrate got a finalized prototype and a documented feature set for engineering. And a team that knows the codebase if you want to keep going.
Tell us what's not working.
Slow pages, a screen users abandon, a payments migration you don't trust, a feature stuck inside the monolith. You'll hear back within two business days with a plan and a rough budget.
