What We Learned in Our First Year as a Product Studio

Starting with a real problem

The best thing we did was not start with an idea. We started with a problem. We needed to issue verifiable certificates and the existing tools were either overpriced, overengineered, or both. So we built what we needed.

That tool became CredoStar. The fact that it started from our own need meant we were our own first users. We could not hide from bad UX or broken workflows because we experienced them ourselves.

If we were starting over, we would do the same thing again: solve a problem we have, then figure out if others have it too.

Small scope, fast shipping

Our first version of CredoStar did three things: create a badge definition, issue it to a recipient, and provide a verification link. That was it. No bulk issuance, no analytics dashboard, no template library.

It was enough. Organizations could use it to issue real, verifiable credentials. Everything else could wait until we understood what actually mattered.

The temptation to build more before launching is real. Every conversation with a potential user surfaces a new feature request. Resist the temptation. Ship the core, learn from usage, then decide what to build next.

What we got wrong about hiring

We initially wrote job descriptions that sounded like they were designed to scare people away. “High ambiguity.” “Zero hand-holding.” “Don’t apply if you need instructions.” We thought this would attract the right kind of people.

It attracted nobody. Good engineers have options. They are not going to apply to a company that opens with hostility. We rewrote our careers page to describe what people would actually build and what working here is actually like. Applications improved immediately.

The lesson: recruiting copy should describe the opportunity, not test the reader’s tolerance for attitude.

Revenue before funding

We chose to focus on revenue before fundraising. CredoStar charges for its service from day one. The amounts are small but the signal is important: people are willing to pay for what we built.

This changes every conversation. With potential hires, we can say “we have paying customers” instead of “we have a pitch deck.” With potential investors (when we get there), we can show traction rather than projections.

Not every startup can do this. Some products require significant upfront investment before they can generate revenue. But if you can charge early, do it. The feedback loop from paying customers is fundamentally different from the feedback loop from free users.

The product studio model

Running a product studio means we own the full lifecycle of everything we build. There is no client to blame when things go wrong and no project end-date to hide behind.

This is harder than doing services work. But the upside is that everything we build compounds. CredoStar gets better every week because we keep improving it. A services project gets delivered and forgotten.

After one year, we have one live product, one in development, and a small team that is getting better at building software every month. That feels like the right pace.