Hammerstone pivots to reporting and commits to Rails only

Executive overview

Hammerstone built a composable query builder for Rails and Laravel developers — but couldn't sell it because nobody knows what a "query builder" is. Customers kept saying they just wanted reports.

Three failed experiments in the Laravel market revealed a low propensity to pay. Rails customers were companies; Laravel customers were hobbyists.

When your positioning is unsellable, the product itself doesn't matter — pivot to what customers are already trying to build.

The reporting pivot

• Front-end UI customisation was the hardest part of the query builder — not the query logic itself
• 85–90% of actual use cases were just reporting anyway
• Customers asked for scheduling, email digests, and custom views — all functionality Hammerstone was telling buyers they could build themselves
• Reporting lets Hammerstone own the full UI and deliver a true drop-in solution
• Nine out of ten prospects shown the reporting mock-up said that was exactly what they were trying to build
• Positioning becomes instantly legible: "reporting dashboard" needs no explanation

Dropping Laravel, doubling down on Rails

• Hammerstone ran three experiments in Laravel: launch, Nova integration, price cut — five, zero, and four sales respectively
• Laravel market showed low willingness to pay; hobbyists dominated
• Rails market attracted companies with real budgets
• Maintaining two frameworks felt like a safety net but meant nothing got enough momentum
• Decision: both co-founders now focus entirely on Rails
• Aaron (the Laravel developer) will learn Rails — his public learning journey doubles as developer-relations content

Hiring with a real process

• Previous hires came from podcasts and friend-of-friend referrals with no written expectations
• When people didn't deliver, there was no job description to point to — failure was inevitable
• New process: write a proper job description, post on Rails job boards, add a short coding challenge in the application form to filter for attention and relevant skills
• Seven intro calls → four coding challenges → one hire
• Network hires are fine; the formal process is what matters, not the source

Transitioning from developer to manager

• Being likeable does not automatically translate into being a good manager
• The hardest skill: giving direct negative feedback without feeling cruel
• Root cause: most people are socialised never to tell someone they're not performing
• One-on-ones are the forcing function — without a scheduled slot, critical feedback never happens
• Cadence: monthly for senior team members, every two weeks for mid-level
• The one-on-one agenda: acknowledge good work, then surface specific issues before they fester
• Colleen's co-founder Aaron helps by asking: "What's the subtext you're not saying?"
• Early mistake: letting developers do whatever they wanted out of fear they'd quit, instead of uniting them behind a shared vision
• Poor management is survivable short-term; at scale it drives attrition