Most engagements start the same way. A client comes to us with a problem and a rough idea of the solution. We scope it, we build it, we ship it. That part is the job description.
The part that doesn't show up in a statement of work is everything we do along the way that isn’t delivering the product itself. Building software well requires developing and maintaining habits that our clients either haven’t had a reason to develop yet or that they know they should be doing, but they lose focus on.
Three examples, three different lessons.
SDES runs a platform that helps special education teachers track student progress. Before we wrote a line of code, we sat down with the teachers and admins who'd actually use it. We tested concepts in Figma, watched people react to screens that didn't work yet, and only started building once we had real signal on what mattered.
That sequence: talk to users, test the concept, then build, seems obvious written down. It's not what most teams default to. The default is to start writing code because writing code feels like progress. SDES's whole business is teaching kids what they don't yet know how to do. We ended up teaching SDES the same kind of lesson, one level up: cheap validation kills expensive guesses, and the fastest way to build the wrong thing is to skip the part where you find out you're wrong for ten dollars instead of ten weeks.
With Ad Hoc Labs, each week we put together a dashboard with metrics from sources like Amplitude, Adjust, AppStore Connect, and the Play Store. Then we sat down together to look at the numbers and make actual business decisions based on data. Not a quarterly report nobody reads. A standing weekly habit of confronting what was actually happening versus what everyone assumed was happening. And we clustered around a TV so everyone leaned into the conversation.
Every team has opinions about what to build next. Fewer teams have the discipline to check those opinions against real usage on a fixed schedule. That’s what we helped build for the Ad Hoc team, the habit of looking at reality on a regular basis so they were attacking the right problems.
Phillips Connect builds sensors and hardware for tractor trailers, and they came to us specifically to be their software partner because that's not their domain. They brought the product people; we brought the developers and designers.
What surprised nobody once we said it out loud (but nobody had said out loud yet) is that having technical expertise in hardware doesn't automatically translate to being good at running a software team. We ended up coaching their side on the mechanics: setting up Jira so every release traces back to a ticket, structuring sprint planning so it produces a real plan instead of a status meeting, running retros that end in action items instead of vibes. Shipping code and running a team that ships code reliably are two different disciplines. Most people who are excellent at one have never been taught the other.
SDES teaches kids. Ad Hoc's business model depends on understanding its users. Phillips teaches hardware engineers to trust the physical world less and the sensor data more. Three Partners, three different domains, and in every case the software we shipped wasn't actually the hardest or most valuable part of the engagement.
The hardest part was teaching the muscle underneath it: validate before you commit, look at real data before you argue, and treat running a team as a skill you build on purpose instead of one you inherit by accident. The product is what ships. The education is what stays after we're gone.
