In My Pocket Labs

The work behind the work

Lessons lived.
Lessons learned.

Not every useful idea becomes a viable product. Some meet a market that is not ready. Some solve the wrong version of the problem. Some simply do not find enough people who want them.

We think those stories belong here too.

01 / WHY SHARE THIS

Building in public means being honest about what did not work.

In My Pocket Labs is a self-taught software studio. That gives us the freedom to see problems differently, move quickly, and try things that larger teams might never attempt. It also means we sometimes learn a lesson the expensive way.

The point is not to celebrate failure. It is to show the judgment that comes after it: recognize the evidence, stop forcing the wrong path, and bring what we learned into the next build.

02 / THE ARCHIVE

Three projects.
Three different lessons.

CASE 01D9Drug court SaaS

AMBITIOUS SYSTEM · STOPPED

The value was real. The path to adoption was not.

D9 began with a problem still worth solving: drug court participants need better access to practical digital tools, while case managers and probation officers carry clerical demands that software could drastically reduce.

But a good outcome was not enough to make the product viable from where we stood. Business associate agreement costs, long court-system decision cycles, the difficulty of getting multiple departments to share data, and institutional fear of liability created a wall that code alone could not remove.

01Compliance cost

BAA requirements changed the cost and operating model.

02Decision speed

Court-system timelines were too long for a small studio.

03Shared data

Multiple departments needed to cooperate across organizational lines.

04Liability

Fear of risk outweighed the appetite for operational improvement.

“I still believe the work matters. I just cannot get there from here.”
WHAT WE CARRIED FORWARD

A product can solve a serious problem and still be the wrong product for the builder, buyer, timing, or institutional environment. Feasibility includes the path to adoption—not just whether the software can be built.

CASE 02ClinTrackClinical workflow app

MARKET MISREAD · STOPPED

We built around an assumption before proving the need.

ClinTrack was a misjudgment about what the market actually needed. The product reflected a problem as we understood it, but we had not gathered enough evidence that buyers wanted this solution in this form.

WHAT WE CARRIED FORWARD

Proximity to a problem is not the same as market validation. Talk to the people who will use, approve, and pay for a product before allowing a strong idea to become a large build.

CASE 03NoBS MoviesMovie discovery app

FIRST APP · LIMITED DEMAND

A product can be likable without being wanted.

NoBS Movies was the first app. We still like its direct, no-nonsense approach to finding something worth watching. But personal enthusiasm did not translate into meaningful market demand.

It remains part of the story because first products teach lessons no tutorial can: how to finish, how to ship, and how to separate affection for the work from evidence that the market wants more of it.

WHAT WE CARRIED FORWARD

Shipping is an achievement, but attention, use, and willingness to pay are separate tests. Let the market answer those questions honestly.

03 / WHAT CHANGED

Every stopped project changed the next one.

We now ask harder questions earlier: Who feels the problem? Who decides? Who pays? What must change besides the software? What is the smallest real-world proof?

Being self-taught means making mistakes other developers may know to avoid. It also means learning without pretending, documenting the evidence, and becoming a better builder with every attempt.

See what we are building now