Frame first
The chosen frame and intended use define the rest of the system.
Product roadmap · Version 1.0
From useful prototype to market-ready product.
A focused 30-day plan for turning Bike Builder into a trustworthy single-speed decision system. The goal is simple: help a rider choose a bike that fits, understand which parts work together and avoid an expensive mistake before buying anything.
- Duration
- 30 days
- Cadence
- One focused update daily
- Scope
- Single-speed MVP
- Outcome
- Beta-ready product
The north star
Plan the right single-speed before buying a single part.
What Bike Builder becomes
Not a decorative configurator and not another catalogue. It becomes a calm decision-support tool that turns a rider's use, body measurements, budget and preferences into an understandable starting specification.
Why it is different
Every recommendation explains its reason, confidence and dependencies. The product should say when something fits, when it conflicts and when the rider still needs to measure or ask a mechanic. Confidence comes before commerce.
Explain the why
No unexplained scores, hidden rules or false precision.
Prevent regret
Surface incompatibility and uncertainty before a purchase click.
Earn trust
Rank by suitability, never by commission or sponsorship.
Customers and their journey
Build for uncertainty, then reward confidence.
Primary customer
The first-time custom builder
Buys parts online, likes the idea of a personal bike and does not yet speak the language of dropout spacing, chainline or bottom brackets.
Secondary customer
The confident enthusiast
Already understands the basics, but wants to validate a build, compare gearing and share a clean specification with a shop or friend.
Later customer
The independent bike shop
Needs a guided pre-sales tool that collects better information and reduces time spent correcting incompatible customer choices.
| Pain today | Gain Bike Builder should create |
|---|---|
| Standards and component language are confusing. | A guided flow in plain language, with optional technical detail. |
| One incompatible part can waste a large part of the budget. | Conflicts appear before shopping, with the reason and a practical fix. |
| Height-only sizing and universal gearing advice feel certain but are not. | Useful ranges, confidence levels and honest requests for measurements. |
| Research is scattered across videos, forums, shops and open tabs. | One build record that connects needs, decisions, parts and unresolved checks. |
| A recommendation can feel arbitrary or sales-driven. | Every recommendation explains why it suits the rider and how money is made. |
- 01DiscoverUnderstand the promise
- 02DescribeUse, fit and budget
- 03RecommendSee a starting specification
- 04ValidateResolve compatibility
- 05KeepSave, compare and share
- 06ActExport or shop confidently
Day 02 · Customer jobs, pains and gains
Every question must earn its place.
The builder is designed first for a new custom-bike buyer who needs a safe starting point, and second for an enthusiast who wants to validate a direction without losing control of the choices.
Primary profile · Guided first build
Make a confident plan without learning every standard first.
Job: turn an intended ride and a total budget into a credible first specification.
Pains: unfamiliar terminology, scattered advice, hidden dependencies and fear of buying the wrong part.
Success: understands the recommendation, its uncertainties and the next check before spending money.
Secondary profile · Confident validator
Check a preferred direction without surrendering the build.
Job: test known preferences and planned parts against a coherent frame-led direction.
Pains: generic advice, repeated beginner explanations and tools that hide the reason behind a verdict.
Success: can compare a small number of meaningful alternatives and take unresolved dimensions to a shop or mechanic.
| Question and user job | Reason for asking | Recommendation consequence |
|---|---|---|
| Build purpose Choose the kind of ride the bike must support. | Sets the overall direction before individual parts. | Changes build type and can alter geometry, gearing and handlebar. |
| Riding environment Prepare for the roads actually used. | Surface quality changes comfort, grip and durability needs. | Changes tire width and can move gearing and frame guidance toward comfort or durability. |
| Priority Choose the tradeoff that should lead. | No single build can maximize every quality at once. | Changes build type, material, geometry, gearing, tires and handlebar. |
| Budget Keep the complete build realistic. | Changes where to invest and how much contingency to keep. | Adds a spending strategy without allowing price to override compatibility. |
| Height Start with safer fit ranges. | Provides an initial estimate without claiming an exact bike fit. | Changes frame-size and crank-length ranges and preserves a fit caveat. |
| Guidance level Control how much decision-making the tool should lead. | Beginners and experienced builders need different next actions. | Changes how the result should be used: shortlist, baseline, comparison or constraint check. |
Five-question interview
- What triggered your last search for a single-speed bike or build?
- Walk me through how you researched the frame and parts.
- Which decision felt most risky, and what evidence would have made it safer?
- Looking at a recommendation, what do you think it is telling you and what remains uncertain?
- What would you do next with the result before buying anything?
Five-question survey
- Have you built a bike before? Never, partly, or completely.
- What are you trying to do? Plan, validate parts, compare options, or prepare to buy.
- What blocks you most? Fit, compatibility, gearing, budget, terminology, or another concern.
- Which proof increases confidence most? A reason, source, dimension check, confidence level, or mechanic review.
- Which output would be most useful? Starting specification, checklist, comparison, share link, or printable sheet.
Day 03 · Competitive gap map
Own the decision before the shopping starts.
Most bike builders begin with a product, frame or catalogue. Bike Builder can credibly own the earlier moment: helping a rider turn real-world needs into a reasoned single-speed plan, while showing what is known, what conflicts and what still needs checking.
| Product pattern | What it makes easy, and where a beginner can still get stuck |
|---|---|
| Fanatik Bike Builder Visual custom builder | Makes a high-end component build tangible and cart-ready. It assumes the rider already understands the available parts and is shopping within a specialist mountain-bike catalogue. |
| Trek Project One Brand configurator | Makes colour, component sizing and curated upgrades feel polished and safe. The journey starts from a Trek model and helps customize a purchase rather than decide what kind of bike should be built. |
| Orbea MyO Brand configurator | Connects component and visual choices to pace and terrain inside Orbea's supported models. It does not create a retailer-neutral plan for a rider sourcing a frame and parts independently. |
| Bike Matrix Compatibility layer | Checks documented replacement-part relationships against a selected bike and retailer catalogue. It is strongest after a bike is known, not while a first-time builder is still defining use, fit and overall direction. |
| BikePartPicker Parts and compatibility planner | Combines a growing catalogue with evidence-backed compatibility and does not turn missing data into a green check. Breadth and technical selection can still place the first decision burden on a beginner. |
| Source BMX Builder Retailer builder | Combines visual assembly, compatible products, save and share in one purchase path. Its value is tied to one bicycle category and one retailer's available products. |
Three defensible product gaps
A narrow place Bike Builder can win.
Gap 01 · Before the catalogue
Start with the rider's job, not a frame or SKU.
Translate purpose, roads, priority, budget and basic fit inputs into a credible starting specification before asking the rider to understand component standards.
Gap 02 · Explain uncertainty
Make reasons, confidence and missing checks visible.
Combine plain-language recommendations with their evidence, dependencies and unresolved measurements instead of presenting a polished choice or compatibility colour without enough context.
Gap 03 · Plan before commerce
Create a neutral single-speed build record.
Let a rider keep, compare, share or take the same reasoned plan to any shop. Retail links may follow later, but they must never decide what the tool recommends.
Product position
Guided decision support for a first single-speed build.
The promise is not “design any dream bike.” It is “reach a safe, understandable starting plan and know exactly what to verify next.” This keeps the product useful before it has a large catalogue.
We will not build
Scope that would weaken the core advantage.
- A 3D or photorealistic bicycle visualizer.
- A giant SKU catalogue, live stock feed or price scraper.
- A full retailer checkout or dealer-order system.
- Coverage for every bicycle category during the MVP month.
- A black-box AI recommendation or a claim of mechanic-level certainty.
- Accounts, social galleries or community features before the core plan is trusted.
Day 01 · Baseline product audit
The product we actually have today.
Verified against the public site and the wordpress branch on 28 September 2026. This is the source-of-truth baseline for the month: future work should improve these foundations, not rebuild them.
| Live route or asset | Verified state on 28 September 2026 |
|---|---|
/ · Landing page | Working hero, light and dark themes, direct start link and complete footer navigation. |
/builder/ · Questionnaire | Working six-step flow covering purpose, roads, priority, budget, height and guidance level. Answers persist locally and the deterministic showcase build works. |
/builder/results/ · Results | Shows build direction, frame, gearing, tires, handlebar and crank guidance plus an 18-category component checklist and sourced technical disclosures. Only six categories are defined and no selected parts are validated. |
/blog/ · Guide index | Working editorial index with three published long-form guides. |
/blog/build-a-single-speed-bike/ | Published beginner build guide with the full component journey and technical illustrations. |
/blog/single-speed-vs-fixed-gear/ | Published comparison guide covering coasting, braking, hubs and beginner suitability. |
/blog/single-speed-gear-ratio-guide/ | Published gearing guide covering ratios, cadence and practical tradeoffs. |
/about/ · About | Working but minimal. It explains the product in one sentence and offers no next action or contact path. |
/updates/ · Roadmap | Working, noindexed operational source of truth with machine-readable daily statuses. |
Existing product foundations
The restrained landing direction, Manrope and Space Grotesk typography, brick-red underlined links, persistent light and dark themes, responsive layout, keyboard-operable questionnaire, local answer recovery, recommendation rules, component dependency copy and three SEO guides are established work to preserve.
Decision rules already in code
Purpose and priority choose a build direction. Height maps to frame-size and crank-length bands. Use, road surface and priority influence material, geometry, a 44T, 46T or 48T chainring with a fixed 17T freewheel, tire-width range and handlebar type. Budget and requested guidance level are collected but currently do not change the result.
| MVP dimension | Evidence and score |
|---|---|
| Problem and audience · 3 / 4 | The single-speed focus and beginner problem are clear. The landing promise still overstates verified compatibility. |
| Questionnaire experience · 3 / 4 | The short, responsive flow works and saves progress. Two collected answers have no consequence and technical rationale is not shown while answering. |
| Recommendation explainability · 2 / 4 | Results include plain-language reasons and caveats, but not a confidence state or source for each recommendation. |
| Compatibility safety · 1 / 4 | Dependencies are explained, but the current model accepts no real component specifications and cannot produce a genuine compatible or conflict verdict. |
| Result usefulness · 1 / 4 | The starting specification is readable, but users cannot complete, compare, save as a named build, share, export or take a verified shopping action. |
| Launch operations · 1 / 4 | The site and guides are live, but funnel analytics, feedback, privacy, affiliate policy, complete business details and a release regression record are absent. |
Prioritized launch blockers
What must be true before marketing.
- P0
Compatibility promise exceeds the engine
The landing page says users can choose components designed to work together, while the MVP currently recommends categories and dependencies without accepting actual part dimensions or producing verified compatibility states. Marketing must wait until this promise and the engine agree.
- P0
Incomplete results fail open
The results route can generate a default specification from absent or incomplete saved answers instead of returning the rider to the missing decision. A recommendation must never look personal when required inputs are unavailable.
- P0
Recommendation confidence is not visible
Fit, gearing, tire, cockpit and crank outputs use deterministic editorial rules, but their evidence, confidence and unresolved dependencies are not attached to each result. High-consequence guidance needs an explicit confidence model.
- P1
Budget and guidance answers do not affect output
Users spend effort answering two questions that currently have no recommendation consequence. Each question must earn its place or be removed.
- P1
The result has no completion path
After reading the result, the only action is Edit Answers. A useful MVP needs at least one safe way to keep, review or export the build before any retailer handoff is tested.
- P1
There is no measured funnel or feedback loop
Starts, abandonment, completion and usefulness are unknown. The release cannot distinguish a trusted recommendation from an unread result.
- P2
Trust pages are incomplete
About is minimal, no clear contact route exists and privacy, analytics and future affiliate disclosures are not yet published.
- P2
Search and edge-state presentation need a QA pass
Footer search exists, but search results, no-results behavior, 404 handling, old saved data and extreme input combinations do not yet have recorded acceptance evidence.
Evidence over assumptions
The MVP earns the right to grow.
Product signals
Measure starts, question-level drop-off, result completion, save, compare, share, export and retailer clicks. Pair the numbers with usefulness ratings and observed usability sessions.
Experience targets
Protect a fast, stable interface: LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1 at the 75th percentile. Critical flows must also work by keyboard and without relying on color alone.
Commercial path
Revenue follows a useful decision.
- 01
Transparent retailer referrals
Link to suitable parts only after compatibility is checked. Disclose affiliate relationships clearly and never let commission change a recommendation.
- 02
Premium Build Report
Test willingness to pay for a polished, downloadable specification with fit notes, compatibility checks and assembly questions. Validate demand before choosing a price or building payment.
- 03
Clearly labelled placements
Consider sponsored alternatives only when they genuinely fit the build and can be distinguished immediately from neutral recommendations.
- 04
Shop edition
Later, license an embeddable intake and compatibility flow to independent retailers. Build this only after the consumer workflow proves useful.
The 30-day build plan
One meaningful release each day.
Each day is deliberately narrow enough for one focused working session. A day is complete only when its acceptance criterion is met, the affected flow is tested and the live deployment is verified.
Phase 01 · Days 1–7
Truth before polish
Define the problem, the user and the route through the product.Day 01
Done
Baseline product audit
Inventory every live route, feature, decision rule, content asset, broken state and dead end. Record what already works so the month improves the product instead of rebuilding it.
Done when: one source-of-truth audit and an MVP scorecard exist, with every launch blocker named and prioritized.
Evidence · 28 September 2026: verified nine public routes, six questionnaire decisions, six of eighteen defined component categories, the current rule set and failure paths. Published the 11 / 24 MVP scorecard and prioritized three P0, three P1 and two P2 launch blockers.
Day 02
Done
Customer jobs, pains and gains
Refine the primary and secondary customer profiles. Write a short interview and survey script, then connect each builder question to a real decision the user is trying to make.
Done when: every question has a user job, a reason for asking and a consequence in the recommendation.
Evidence · 29 September 2026: refined the two launch customer profiles, published five-question interview and survey scripts, and mapped all six builder questions to a user job, reason and recommendation consequence. Added keyboard-accessible “Why we ask” disclosures and made budget and guidance level change the live result.
Day 03
Done
Competitive gap map
Compare visual configurators, compatibility tools and retailer builders. Identify what they make easy, where beginners still get stuck and which problems Bike Builder can credibly own.
Done when: three defensible product gaps and a clear “we will not build” list are documented.
Evidence · 30 September 2026: the competitive map is complete and live. It identifies guided decision-making, connected component dependencies and progressive refinement as the product gaps Bike Builder can credibly own.
Day 04
Planned
Journey and information architecture
Map three product depths: six-question Quick Build, conditional Refine Build and optional Refine Fit. Connect the same result to compatibility explanations, educational content, suitable products and contextual professional-fit help.
Done when: every depth returns to one build result, has a clear way back and never makes the quick result feel unfinished.
Day 05
Planned
Conditional refinement architecture
Keep the six essential questions as the fast entry point, then define optional questions by ID, category, answer type, affected components, dependencies and appearance conditions. Include “I’m not sure” and Skip behavior.
Done when: relevant questions can be added without rebuilding one large form, and users never have to answer details that cannot change their result.
Day 06
Planned
Component refinement UX
Test individual “Refine recommendation” interactions, component-specific questions, subtle update feedback, exit and back behavior, preserved answers and focused mobile sheets without permanently enlarging every card.
Done when: a rider can refine one component without entering a second full questionnaire or losing the original build.
Day 07
Planned
Week-one QA and baseline
Regression-test the landing page, builder, results, guides, search, footer, light and dark themes, and common mobile widths. Record the starting funnel and performance baseline.
Done when: critical paths are stable on mobile and desktop, with baseline evidence saved for later comparison.
Phase 02 · Days 8–14
Make the engine trustworthy
Replace confident-looking output with explainable fit and compatibility logic.Day 08
Planned
Recommendation schema and source audit
Normalize every output into value, reason, qualitative state, dependencies, affected answers and source. Separate verified rules from assumptions, user-provided references and editorial suggestions.
Done when: every recommendation can explain which answers changed it and whether it is Starting, Refined, Fit-informed or Confirmed compatibility.
Day 09
Planned
Component dependency graph
Model frame and fork standards, wheel size, rear spacing, dropout type, brake mounts, bottom bracket shell, headset, seatpost, drivetrain mode and tire clearance as connected constraints.
Done when: each answer identifies the affected components, and each unresolved dependency says which component or standard is needed next.
Day 10
Planned
Fit engine and self-measurement MVP
Combine height, riding position and only useful body measurements such as inseam, torso, arm and shoulder width. Add clear measuring instructions and illustrations, then refine frame, cockpit, handlebar and crank directions with safe wording.
Done when: credible bicycle-fitting guidance has been used to test the rules and the interface never presents self-measurement as a professional fit.
Day 11
Planned
Professional-fit import
Define fields for saddle height, setback, reach, drop, handlebar width and crank length. Record whether the source bike was road, gravel, triathlon, urban or another type, then research safe transformations between contexts.
Done when: imported fit data can inform a recommendation without blindly copying an aggressive or category-specific position.
Day 12
Planned
Compatibility states and explanations
Connect fork and headset, wheel and brake, rim and tire, crank and bottom bracket, and chainring, sprocket and chainline. Use clear Recommended, Can be refined, Depends on another component and Confirmed states with source-backed explanations.
Done when: each conflict or dependency names the cause, affected components, missing evidence and at least one valid resolution.
Day 13
Planned
No-clutter results hierarchy
Keep answers and Edit answers above the component scroll, place optional build and fit refinement in context, and move technical or component-specific detail behind focused disclosures.
Done when: mobile users can understand and change the build without competing CTAs, oversized cards or unnecessary page jumps.
Day 14
Planned
Rule and refinement test suite
Test commuters, fast and longer-distance riders, rough roads, height edges, unknown answers, conditional question paths, component refinements, self-fit inputs and source-bike fit transformations.
Done when: tests prove that meaningful answers change the intended components, unnecessary questions stay hidden and every uncertainty tells the rider what can resolve it.
Phase 03 · Days 15–21
Make the result useful
Turn a one-time recommendation into a build the rider can keep, compare and act on.Day 15
Planned
Save and resume
Persist a build locally with schema versioning, clear privacy language and graceful recovery when saved data becomes outdated or incomplete.
Done when: a refresh or later visit restores the build, and old data fails safely without a blank or broken screen.
Day 16
Planned
Shareable build
Create a privacy-safe link or structured copied summary that preserves the decisions, recommendation version and unresolved checks.
Done when: another person can reproduce and review the same build from the shared output.
Day 17
Planned
Compare meaningful alternatives
Let a rider compare two gearing, tire or cockpit directions. Show only changed choices, consequences and unresolved constraints.
Done when: the comparison helps a decision without repeating the entire build or creating data overload.
Day 18
Planned
Exportable build sheet
Create a print and PDF-friendly specification with decisions, dimensions, compatibility notes, unresolved checks, rule version and date.
Done when: the sheet is readable without the website and useful in a conversation with a bike shop or mechanic.
Day 19
Planned
Bike-fitter directory structure
Research independent fitters and design a neutral future directory for location, pricing, fitter information, booking links, referral URLs, codes and clearly marked sponsored placement. Do not publish unconfirmed partners.
Done when: real providers can be added later without changing the fit flow, and an empty directory never implies a partnership.
Day 20
Planned
Fitter referral economics and outreach
Contact potential fitters and investigate confirmed-appointment fees, commission, qualified leads, referral codes and tracked booking links. Compare economics without choosing a model before partner evidence exists.
Done when: candidate terms, partner requirements and user-protection criteria are documented from real conversations.
Day 21
Planned
Honest monetization experiment
Add affiliate and referral disclosures, test interest in component shortlists, a premium Build Report and optional fitter referrals, and plan later click-to-booking measurement. Measure intent before building checkout or inventing partner revenue.
Done when: commercial content is unmistakably labelled and neither product commission nor fitter referral value can influence compatibility or fit guidance.
Phase 04 · Days 22–28
Trust, growth and launch
Make the value easy to understand, the product easy to find and the evidence easy to read.Day 22
Planned
Landing value proposition
Sharpen the hero and supporting content around fit, compatibility and avoided mistakes. Preserve the restrained visual identity and provide an immediate path into the builder.
Done when: a first-time visitor can explain the value within five seconds and start without searching.
Day 23
Planned
Search content map
Map high-intent questions to builder states and plan only three genuinely useful articles. Improve internal paths between guides and the relevant decision in the product.
Done when: each page solves a distinct rider job and leads naturally to an applicable builder step, without scaled filler.
Day 24
Planned
Technical search foundations
Verify sitemap, robots directives, canonical URLs, structured data, page titles, descriptions, breadcrumbs and crawlable internal links. Keep this operational roadmap out of search results.
Done when: every public product and guide page has one canonical URL and all important routes are discoverable by crawlers.
Day 25
Planned
Performance pass
Audit font loading, images, JavaScript, caching and layout dimensions. Remove work the browser does not need and preserve the product's quiet, immediate feel.
Done when: measured pages target LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile.
Day 26
Planned
Privacy, legal and accessibility readiness
Add appropriate privacy, analytics and affiliate information, verify the need for consent, and provide genuine contact or business details. Run an accessibility audit of critical paths.
Done when: no tracking or commercial relationship is hidden and no critical accessibility failure remains unresolved.
Day 27
Planned
Feedback in context
Add a lightweight usefulness rating, compatibility issue report and contact route. Attach the relevant step and build version so users do not need to reconstruct their problem.
Done when: feedback identifies the affected state while collecting only the information needed to investigate it.
Day 28
Planned
Decision-focused analytics
Measure completion of essential questions, build and component refinement, self-fit and professional-fit paths, Edit answers, fitter interest and compatible-product handoffs. Test which optional questions create meaningful changes and which should be removed.
Done when: the funnel and refinement usefulness can be read end to end without sending body measurements, detailed answers or other sensitive data.
Release · Days 29–30
Prove, release, decide
Finish with observed use and an evidence-based decision about what comes next.Day 29
Planned
Closed beta kit and sessions
Prepare a neutral test script, recruitment message, five-to-ten-session target, severity rubric and concise launch FAQ. Observe behavior before asking for opinions.
Done when: every recorded issue includes evidence, severity, owner and a decision to fix, monitor or decline.
Day 30
Planned
Release candidate and business gate
Back up, run the full regression suite, fix launch blockers, review customer and monetization evidence, and choose Month 2 work from observed needs rather than enthusiasm.
Done when: the product is usable on mobile and desktop, has no known critical compatibility defect and has one evidence-based commercial next step.
Scope protection
Not in Month 1.
These may be valuable later, but they would dilute the core promise before it has been proven.
- A full 3D bicycle configurator
- Thousands of product SKUs
- Retailer inventory or price scraping
- User accounts and cloud sync
- Every bicycle category
- An AI chat concierge
Month 2 candidates: expand the rule base, add verified product feeds, test paid reports, add accounts or build a shop pilot only when Month 1 data demonstrates the need.
Operating protocol
How each daily update should run.
- 01
Read the source of truth
Open this page, find the first day marked Planned and review its task, acceptance criterion and dependencies. Do not silently skip a blocked day.
- 02
Inspect before changing
Review the current live flow and source files. Preserve completed work, the landing direction, typography, color system and unrelated user changes.
- 03
Keep the daily scope small
Deliver one major change or at most two tightly related small changes. If the task is larger, ship the safest coherent slice and record the remainder.
- 04
Test the acceptance criterion
Check the affected path on desktop and mobile, light and dark mode, keyboard navigation and failure states. Run relevant automated checks when available.
- 05
Deploy and verify
Commit the exact change, deploy it to the live WordPress site and verify the public URL. A local or repository-only change does not count as complete.
- 06
Update this roadmap
Change the day's machine-readable
data-statusand visible label to Done, add a brief evidence note with the deployment date and leave the next unfinished day as the next task.
Daily definition of done
- The change directly serves the day's stated user outcome.
- The acceptance criterion has observable evidence.
- No known regression exists in the builder or landing page.
- Accessibility and responsive behavior were checked.
- The live deployment was opened and verified.
- This page records status, evidence and the next task.
Research anchors
Standards behind the plan.
- Google web.dev: Core Web Vitals
- W3C: WCAG 2.2 Quick Reference
- Google Search: helpful, reliable, people-first content
- KVK: affiliate marketing and disclosure
- Bike Matrix: market example for component compatibility
- BikePartPicker: market example for guided parts selection
Plan created 28 September 2026. Review after Day 7, Day 14, Day 21 and Day 30. Change sequence only when evidence, a blocker or user direction justifies it.