How I Built BuildRoadmaps: A Free Canny Alternative in 40 Days (With Real-Time Multiplayer)

The full story of building a free Canny alternative with real-time multiplayer — and why building your own tools is a business strategy.

Canny charges $400/month. I built BuildRoadmaps in 40 days with real-time multiplayer presence, four visualisation modes, and anonymous voting — for free. Here is why building your own tools is a business strategy.

I needed a roadmap tool for my own products. Canny charges $400/month. ProductBoard starts at $25/user. For an early-stage product with ten users, paying enterprise pricing for feature voting feels absurd.

So I built one. BuildRoadmaps went from first commit to production in 40 days. It's free. It has real-time multiplayer presence. And I use it every day to manage the roadmaps for my own products.

This is the story of building the tool I wanted to exist — and why building your own tools is sometimes the best business decision you can make.

Why I built it

The roadmap tool market has a gap. At the bottom, you have GitHub Issues and Notion boards — functional but invisible to your users. At the top, you have Canny, ProductBoard, and LaunchNotes — powerful but expensive for early-stage products.

The missing middle is a tool that lets founders share a polished roadmap with their first 100 users, collect votes and feedback, and show progress transparently — without paying $4,800/year for the privilege.

I wanted four things: public roadmaps users could vote on, real-time collaboration (like Figma), a way to show customers what's being built and why, and zero cost to run.

Nothing on the market hit all four. So I opened Replit and started building.

What I built: real-time multiplayer product roadmaps

BuildRoadmaps gives founders a public-facing roadmap platform with features that rival tools costing $400/month.

Real-time multiplayer presence. Figma-style live cursors showing exactly where other users are looking and what they're interacting with. Coloured avatars and name badges update in real-time across unlimited concurrent viewers. This isn't a gimmick — it shows users that the roadmap is alive, that other people care about these features too.

Four visualisation modes. Kanban board with drag-and-drop for managing workflow stages. List view for quick scanning. Timeline view for release planning. Changelog view for shipped features organised by month. Users consume roadmap data in whatever format suits them.

Instant voting. One-click upvoting with optimistic UI updates that reflect changes before server confirmation. The perceived latency is under 50ms regardless of actual network speed. Users feel the product is responsive, which matters more than it should.

Threaded comment discussions. Full comment system with @mentions that trigger email notifications, like counts, founder badges, and file attachments. All updating in real-time across every viewer.

Multi-tenant brand architecture. One founder can manage unlimited brands and roadmaps from a single account. Hierarchical data model: Brand → Roadmap → Feature — each with custom slugs for clean, shareable URLs like /acme/mobile-app instead of UUID-based paths.

Granular access controls. Public, private, unlisted, and password-protected roadmaps. Session-based password verification so protected roadmaps stay accessible during a browsing session without repeated password entry.

Feature lifecycle tracking. Four-stage workflow (Suggested → Planned → Building → Shipped) with timestamp tracking at each transition and automatic activity feed generation.

The technical stack: React 19, TypeScript, Express, InstantDB (real-time database), Tailwind CSS v4, Framer Motion, Google OAuth, magic link auth, and Brevo for transactional emails. 40+ React components. 181 commits.

The technology decision that saved two weeks

The biggest architectural choice was using InstantDB instead of PostgreSQL with a custom real-time layer.

Building real-time sync, presence tracking, and offline support from scratch would have added two or more weeks. InstantDB provides all three out of the box with a simple React hook interface. Presence features (live cursors, viewer counts) took hours instead of days.

The tradeoff is vendor lock-in. InstantDB is a managed service — if it disappears, the data layer needs replacing. For a free product without revenue pressure, speed to market outweighed portability concerns. For a paid product, I'd make a different choice.

Sub-second sync latency across all connected clients. Zero custom WebSocket code. The best feature I shipped was the one I didn't build: InstantDB handles offline sync, conflict resolution, and presence. I just wrote React components.

Optimistic updates: the invisible feature that makes everything feel fast

Every user interaction in BuildRoadmaps updates the UI before server confirmation. Click upvote — the count changes immediately. Post a comment — it appears instantly. Drag a feature to a new column — it moves without waiting.

This pattern — "assume success, rollback on failure" — transforms perceived performance. The actual network roundtrip might be 200ms. The user perceives 50ms because the UI already updated.

Implementing this everywhere requires confidence in the data layer. InstantDB's transaction system handles rollbacks automatically, so if the server rejects a change, the UI reverts without custom error handling for each interaction. This let us apply optimistic updates to everything without building bespoke rollback logic for 40+ interaction types.

Anonymous voting: lowering the barrier to engagement

Most roadmap tools require sign-up before any interaction. BuildRoadmaps lets anonymous visitors vote immediately. No sign-up, no email, no friction.

We generate persistent visitor IDs for anonymous users. Their votes count. Their preferences accumulate. When they eventually sign in (via Google OAuth or magic link), their existing votes persist and link to their authenticated account seamlessly.

This design choice came from a simple insight: forcing sign-in before voting kills engagement. The value proposition of a roadmap tool is "your voice matters." Making people create an account before they can voice an opinion contradicts that promise.

The technical challenge was maintaining vote integrity across the anonymous-to-authenticated transition. Visitor IDs persist in browser storage. On authentication, votes transfer to the new account. Duplicate vote prevention works across both anonymous and authenticated states.

The dark-first UI decision

BuildRoadmaps was built dark-first — dark mode is the default, light mode is the option. This is a deliberate audience decision, not an aesthetic one.

Developers and startup founders — the primary audience — overwhelmingly prefer dark themes. Building dark-first means the primary experience is polished and intentional. Light mode is the afterthought, not the other way around.

Tailwind CSS v4's new colour system made this straightforward with CSS custom properties. Consistent contrast ratios and accessible colour choices across all 40+ components.

What I learned building my own product

The best market research is personal frustration. I didn't survey 1,000 founders about their roadmap tool preferences. I was annoyed at paying $400/month for feature voting. That's enough.

40 days is enough. From first commit to production with real-time multiplayer, four visualisation modes, threaded comments, multi-tenant architecture, and granular access controls. The timeline was possible because I wasn't waiting for anyone's approval, and I was using my own BuildKits methodology to scope the build before writing code.

Own your tools. BuildRoadmaps costs me nothing to run. It does exactly what I need. Every feature request comes from actual usage, not hypothetical user stories. And it's a living case study for client conversations: "this is what a 40-day build looks like."

Frontend-first development works. The UI was functional before the backend was complete. I could share screenshots and get feedback from day 3. By the time the real-time layer was connected, the interface had already been refined through multiple iterations.

Why building your own tools is a business strategy

BuildRoadmaps isn't a side project. It serves three business purposes:

Proof of work. When a prospect asks "can you really build a production SaaS in 30-40 days?", I share the link. They can use it, vote on features, and see the quality firsthand. It's more convincing than any portfolio screenshot.

Methodology demonstration. The build process — frontend-first development, BuildKits specification, real-time architecture choices — is the same process I use for client builds. The tool is a live demonstration of how I work.

Ecosystem value. Every Hello Crossman client product can embed a BuildRoadmaps roadmap. Their users vote on features. Their roadmaps stay public and transparent. It creates network effects across the client portfolio.

This is the same logic behind BuildKits (specification generation), TestFlow (client testing), and ClearMetrics (analytics). Each tool started as something I needed. Each became something clients benefit from. Each demonstrates capability in a way portfolios and case studies can't match.

---

Frequently asked questions

Is BuildRoadmaps really free?

Yes. No paid tier. No credit card required. No feature limits. The tool exists to solve a problem I had and to demonstrate what a focused 40-day build produces.

How does BuildRoadmaps compare to Canny?

Canny is more mature with deeper integrations, changelog automation, and priority boards. BuildRoadmaps has real-time multiplayer presence that Canny doesn't, costs $0 vs $400/month, and supports multiple brands from one account. For early-stage products with under 1,000 users, BuildRoadmaps does everything you need.

What technology is BuildRoadmaps built on?

React 19, TypeScript, Express, InstantDB for real-time data, Tailwind CSS v4, Framer Motion, Google OAuth, magic link authentication, and Brevo for email. Deployed on Replit Autoscale.

Why not just use GitHub Issues or a Notion board?

They're not customer-facing. A roadmap tool should let your users see what's coming, vote on what matters to them, and feel heard. GitHub Issues and Notion boards are internal tools — they don't create the transparency and engagement that BuildRoadmaps does.

---