DEV Community

speed engineer
speed engineer

Posted on

Two Products, One Year, Endless Lessons: A Founder's Honest Recap

Two years ago, I was a freelancer who was terrible at one thing: tracking my time accurately.

I'd finish a project, stare at a blank timesheet, and try to reconstruct three weeks of work from memory and Slack messages. Sound familiar?

That frustration became FillTheTimesheet — a smart timesheet manager built specifically for freelancers and small agencies who hate admin work.

Lesson 1: Solve Your Own Problem First

The best products don't start with a market analysis. They start with a person who was genuinely annoyed.

FillTheTimesheet came from my pain. That meant I knew exactly what the product needed to do from day one: reduce friction. Every feature had to pass one test: does this make logging time faster or slower?

If you're building something, start with the problem you personally understand deeply.

Lesson 2: Distribution Is the Product

I had a working timesheet tool by month two. I thought the hard part was over.

It wasn't.

Getting people to find the product was 10x harder than building it. I started writing about time management, freelancing workflows, and productivity on DEV.to, Medium, and LinkedIn. Slowly, organic traffic started coming in.

Content isn't a nice-to-have. It is distribution when you have no marketing budget.

Lesson 3: Your Second Product Hides Inside Your First

While building FillTheTimesheet, I kept watching my marketing team struggle with something else entirely: they were using AI tools — ChatGPT, Claude, Gemini — every day, but their best prompts lived in random Notion docs, Slack messages, and people's heads.

Every time someone new joined the team, the institutional knowledge of how to use AI well was lost.

That problem became PromptShip — a shared prompt library for non-technical teams. Marketing, Sales, HR, Support — people who use AI daily but aren't engineers.

The lesson? The problems your first product exposes often point directly to your second one.

Lesson 4: Non-Technical Users Have Completely Different Needs

Building for developers is one thing. Building for a marketing manager who has never heard of a "system prompt" is another.

PromptShip forced me to strip every technical concept out of the interface. No jargon. No configuration. Just: here are your team's prompts, click to copy into ChatGPT.

The constraint made it a better product.

What I'd Tell Myself at Day One

  • Ship ugly. A half-polished product in real users' hands beats a perfect product that never ships.
  • Write publicly. The audience you build with content is the most durable marketing asset you have.
  • Talk to users weekly — not monthly. Your assumptions have a short shelf life.
  • The second product will make more sense than the first. Because you'll actually know something by then.

Building in public is uncomfortable. But the feedback loop is worth it.

If you're a freelancer dealing with timesheet chaos, check out FillTheTimesheet. If your team's AI prompts are scattered everywhere, PromptShip has a free plan with 200 prompts — no credit card needed.

What's the biggest lesson you've learned in your first year of building? Drop it in the comments.


Written by The Speed Engineer — building FillTheTimesheet and PromptShip

Top comments (0)