Your product's name. Keep it short, memorable, and reflective of what it does or who it's for. Don't overthink it at this stage — a working name is fine. You can always refine it later.

💡 Say it out loud. If it's hard to spell or explain, it may create friction when talking to developers or investors.

Describe the specific frustration your product is designed to fix. Name who feels the pain, what triggers it, and what goes wrong when it's not addressed. The more specific you are here, the sharper every other decision in your scope becomes.

💡 Avoid abstract statements like "people struggle with productivity." Instead, try something like: "Freelance designers lose 3–5 hours a week re-explaining project status to clients because there's no shared view of progress."

Explain how your product fixes the problem you just described. This isn't a feature list — it's a one or two sentence explanation of the mechanism. How does your product change the situation for the user?

💡 A strong solution statement connects directly to the problem. If someone read both back to back, the solution should feel like a direct answer. If it feels generic, make it more specific.

A brief, plain-language overview of your product. Think of it as your elevator pitch: what it is, who it's for, and what it does — in two or three sentences.

💡 Pretend you're explaining this to a friend who has no idea what you're building. If they'd get it immediately, you're in good shape. If they'd have follow-up questions, keep refining.

The primary objective you're trying to achieve with this version of the product. Not every goal for every future version — just the most important thing this build needs to accomplish.

💡 "Validate that non-technical founders will pay for a guided scoping tool" is a goal. "Build a great product" is not.

Define what a successful launch looks like in concrete, measurable terms. These become your acceptance test — the bar the finished product has to clear before you consider this version done.

💡 Think in specifics: number of users, actions completed, revenue generated, or qualitative feedback received. If you can't measure it, it's not a criterion — it's a hope.

This tells your technical team what kind of thing you're building at the most fundamental level. It shapes architecture, tooling, and timeline before a single feature is discussed.

💡 A Custom Application is a standalone product users sign into — the most common choice for founders. A Custom Website is primarily informational with minimal user logic. A Custom API is a backend service other apps connect to. A Custom Plugin extends an existing platform like Shopify or Figma. A Custom Browser Extension enhances other websites. A Custom Database is a data layer supporting another system.

Where is this product in its lifecycle right now? This helps set context for anyone reading your scope.

💡 Be honest — there's no wrong answer. If you've started building but haven't launched, pick In Development. The stage affects how technical reviewers interpret your scope and what they'll prioritize.

The category that best describes what your product does, based on how apps are classified in the App Store and Google Play Store.

💡 Pick the category a user would naturally search when looking for something like your product. If it could fit multiple categories, go with the one that best reflects your primary use case.

The start date and expected completion date for this project. These define your development window.

💡 If you don't have firm dates yet, use your best estimate. Rough dates are still useful — they help developers flag whether a timeline is realistic before any work begins.

The minimum and maximum amount you're prepared to invest in development. Enter a range rather than a single number — it gives developers room to propose solutions that fit your constraints.

💡 Be as honest as you can here. Developers use this to scope what's feasible, not to maximize what they charge. If your budget is tight, say so — a good developer would rather right-size the build than oversell you.

Define who you're building for. You can add more than one audience, but resist the urge to add too many — the more specific you are, the better every product decision becomes.

💡 For each audience, fill in four things: a name (e.g. "Solo Founder"), a description of who they are, their top pain points related to your problem, and the specific value your product delivers to them. Think of each entry as a mini user persona.

Identify the products your target users are currently using to solve the same problem — even if those solutions are imperfect or indirect. A competitor can be a spreadsheet, a manual process, or a general-purpose tool people are hacking together.

💡 For each competitor, note their name, what they're used for, and where they fall short for your user. Three to five well-understood competitors is more valuable than a long list of surface-level comparisons.

Describe what makes your product the better choice for your target user. This isn't about being better in every way — it's about being meaningfully better for the specific person you're building for.

💡 "We're easier to use" is weak. "We're the only tool built specifically for non-technical founders who have never written a scope before" is strong.

List the capabilities your product will have. For each feature, give it a name, describe what it does, and list its functions — the specific actions a user can take within it.

💡 Don't confuse features with requirements. A feature is a capability (User authentication). A requirement is a specific behavior (The system must allow users to sign up with an email and password). You'll write requirements separately — for now, focus on what the product can do.

List every third-party tool, service, or API your product needs to connect with — a payment processor, an email service, a mapping API, a CRM — anything outside your product that it needs to talk to.

💡 "Stripe for processing subscription payments" is more useful than just "Stripe." Be specific about the use case for each integration.

The tangible outputs this project will produce beyond just the working product — a design system, API documentation, a data export, an onboarding guide, or a test report.

💡 This field is optional at the scoping stage. It's most useful when working with an agency or contractor who needs clear agreement on what gets handed off. If you're still exploring the idea, skip it and come back once you have a development partner in the conversation.

The major checkpoints in your development timeline. Milestones break the project into meaningful phases and give you natural moments to review progress, adjust scope, and make decisions.

💡 This field is optional at the scoping stage. A good milestone marks something significant — a working prototype, a completed feature set, a beta release. These are often defined collaboratively with your dev team once you have one.

The specific, testable behaviors your product must exhibit — the technical translation of your features, precise enough that a developer could build to them and a tester could verify them.

💡 This is an Advanced field — best completed with your developer or technical partner. If you attempt it yourself, write each requirement starting with "The system must..." — this forces specificity. "The system must send a confirmation email within 60 seconds of sign-up" is a functional requirement. "Email confirmations" is not.

The qualities your product must have beyond specific features — speed, security, reliability, accessibility. These define how the system behaves, not just what it does.

💡 This is an Advanced field — best completed with your developer or technical partner. Most founders haven't thought about performance thresholds, encryption standards, or accessibility compliance. Share your priorities in plain language and let your technical team translate them into requirements.

Anything that limits how this project can be executed — budget caps, hard deadlines, technology restrictions, regulatory requirements, team size, or existing systems you can't change.

💡 This is an Advanced field — best completed with your developer or technical partner. You likely know your budget and deadline, but your developer will help surface the technical constraints that matter most. Document what you know and flag the rest for that conversation.

How will this product be built? This is one of the most consequential decisions in your scope — it determines what kind of development team you need, how fast you can move, and what's possible to build.

💡 This is an Advanced field — best decided in conversation with a developer. Traditional Code gives you the most flexibility but requires experienced developers. No-Code / Low-Code tools let you build faster and cheaper but have limits on complexity. Vibe Coding and A.I. Prompting are newer approaches best paired with technical oversight. Don't lock this in before you've had that conversation.

The primary language your product will be written in. Available options update based on your Code selection.

💡 This is an Advanced field — you don't need to have an opinion here. This is best left to your technical partner. If you have existing systems or strong preferences, note them in plain language. Common choices include JavaScript for web and mobile, Python for data-heavy or AI applications, and Swift or Kotlin for native mobile apps.

The pre-built structure your developers will use to build on top of the programming language. Available options update based on your language selection.

💡 This is an Advanced field — primarily a technical decision. Share your priorities (cross-platform mobile, fast page loads, strong SEO) and let your technical team advise. A wrong pick here has real downstream consequences — don't guess.

The system that will store and organize your product's data. Options are filtered based on your language and framework selections.

💡 This is an Advanced field — you don't need to pick one yourself. Instead, share relevant context: Do you need real-time data updates? Are you storing large files or media? Do you have compliance requirements around data location or encryption? These inputs shape the recommendation.

Where will users access your product? This is one of the earliest and most consequential decisions — different platforms require different codebases, design systems, and development approaches.

💡 Start narrow. Most successful products launch on one platform first. If you're targeting professionals at a desk, Web is usually the right call. If you're targeting consumers on the go, Mobile. Each additional platform adds significant development time and cost — be intentional.

The core objects your product needs to store and work with — the nouns of your product. Think: Users, Projects, Tasks, Messages. For each, you'll define the specific pieces of information it holds.

💡 This is an Advanced field — best completed with your developer or technical partner. You can describe your data in plain language (e.g. "I need to store user profiles, their projects, and the tasks within each project") and let your technical team translate that into a formal data model.

Predefined lists of choices that appear as selectable options throughout your product — the dropdowns and radio buttons your system needs to know about.

💡 This is an Advanced field — best completed with your developer or technical partner. You might know the concept (a Task has a Status: To Do, In Progress, Done) but structuring them formally requires technical judgment. Describe the choices you envision and let your developer define the structure.

A simple yes or no: does this product need to handle money? That means accepting payments, issuing refunds, managing subscriptions, or selling anything — digital or physical.

💡 Even if payments are phase two, answer Yes if you know they're coming. Bolting payment infrastructure onto an existing product later is significantly more expensive than building with it in mind from the start.

Describe your overall approach to generating revenue. This is the business logic behind how money flows — not the specific prices, but the structure.

💡 Common models: Freemium (free base, paid upgrades), Subscription (recurring billing), One-Time Purchase (single payment for lifetime access), and Usage-Based (charge per action or document). Start with the simplest one that makes your business work.

The specific things you'll sell — subscription tiers, one-time purchases, or individual services. Each entry defines a single purchasable item with its pricing structure.

💡 For each item, define: its name, a brief description, whether it's a product or a service, its price, how it's priced (flat rate, packaged bundle, graduated tiers, or volume-based), whether it's a one-time or recurring charge, and the billing period if recurring.

The third-party service that will handle the actual movement of money — charging cards, processing refunds, managing subscriptions, and sending payouts.

💡 Stripe is the most common choice for software products — excellent developer tools, supports most business models, and handles international payments well. This decision affects how your backend is built, so lock it in before development starts.

The color palette for your product. Each color has a name and a hex code — the six-character code that defines an exact color digitally (e.g. #3a4d8f).

💡 At minimum, define a primary color, a background color, and a text color. Most design systems also include a secondary or accent color, plus colors for states like errors (red), success (green), and warnings (yellow). Tools like Coolors or Adobe Color can help you build a palette if you're starting from scratch.

The typefaces used across your product and where each one appears. Good typography creates hierarchy and makes your product easier to read and navigate.

💡 Most products use two fonts: one for headings (often bolder and more expressive) and one for body text (clean and readable at small sizes). For each font, define the family name, the size and weight for that context, line spacing, letter spacing, and where it's used (e.g. Heading, Body, Button, Caption). Google Fonts is a free resource with hundreds of quality options.

Upload your logo file. It will appear on your exported scope document and any shared outputs generated from Knocode.

💡 If you don't have a final logo yet, a working version or placeholder is fine — you can update it later. Use PNG with a transparent background or SVG if possible. Avoid JPEG, as the white background can look unprofessional on colored surfaces.