This is the living reference used by Build Compass to make recommendations.
Updated July 23, 2026 · Version 0.5
This is the living reference used by Build Compass. It contains the decision model, tool comparisons, definitions, and safety guidance behind the skill’s recommendations.
Contents
- Choose what you are building
- Write the one-page plan
- Choose the simplest approach
- Match features to technical pieces
- How the pieces fit together
- Tool and platform guide
- Common starting points
- Safety, cost, and maintenance
- Glossary
- About this guide
Choose what you are building
The first decision is not which framework to use. It is what kind of job this is.
Personal workflow
A personal workflow helps you do something for yourself: organize research, prepare for meetings, plan meals, summarize documents, or run a repeated process.
Start with the AI assistant or productivity tools you already use. Add reusable instructions, a skill, a connector, or a small automation only when the repeated workflow requires it. Most personal workflows do not need a standalone application.
Prototype or initial product
A prototype tests whether an idea is useful. An initial product serves a small, real group while you learn what they need.
Optimize for speed, learning, managed services, and the ability to change direction. The first version should complete one valuable workflow from beginning to end. It does not need every future feature, but it still needs reasonable privacy, security, and reliability for the people using it.
Production product
A production product is something people or a business will rely on. Downtime, incorrect permissions, lost data, security failures, or surprise costs can cause real harm.
A prototype can still be the right starting point. The difference is that the path should include qualified engineering review before a wider launch when the product handles sensitive data, payments, complex permissions, regulated work, substantial traffic, or important business operations.
| Type | Optimize for | Default starting point |
|---|---|---|
| Personal workflow | Convenience and low maintenance | Existing AI or productivity tool |
| Prototype or initial product | Learning and a complete core workflow | Managed product, builder, or simple custom app |
| Production product | Reliability, security, and operational ownership | Deliberate architecture plus engineering review |
Write the one-page plan
Before choosing tools, describe the idea in plain language. A useful plan can fit on one page.
- Purpose: What problem does this solve?
- User: Who will use it?
- Core journey: What happens from beginning to end?
- First version: What must work now for it to be useful?
- Later: What can wait until the first version proves itself?
- Constraints: What matters about budget, timing, privacy, existing tools, and maintenance?
For example:
I run a car-detailing business with one partner. Customers should be able to request a quote, book a time, or contact us. We need one private place to see each request and track what happened. For the first version, we do not need a custom mobile app, complex reporting, or automated marketing.
This is enough to compare a specialized service-business product with a custom website. It is much more useful than beginning with “I need a dashboard” because a dashboard is only one possible way to solve the underlying workflow.
If you are unsure how to write the plan, ask an AI assistant to interview you or “grill me on this idea until the first version is clear.” Good AI output depends heavily on clear context, priorities, and constraints.
Choose the simplest approach
Evaluate these levels in order. Move to a more complex level only when a confirmed requirement rules out the simpler one.
1. Existing product or manual workflow
Use a product already designed for the job, or improve the current process with a checklist and clear ownership.
This is often best for common business workflows such as scheduling, quotes, customer tracking, newsletters, commerce, reservations, or field services. The tradeoff is recurring cost and less control over the exact experience.
2. Document, form, spreadsheet, or database view
Use a document for guidance, a form for intake, a spreadsheet for tracking, or a lightweight database view for structured records.
This is a strong choice for personal tools and small internal workflows. It becomes awkward when many users need separate permissions, the customer experience matters, or the process contains too many manual handoffs.
3. Static website
Use a static site when everyone sees essentially the same information and the site does not need private accounts or shared data that changes.
Portfolios, guides, landing pages, menus, event pages, and documentation often belong here. A contact form can be added through a managed form or email service without turning the entire site into an application.
4. Browser-only tool
Use a browser-only tool when the page needs interaction or calculations but does not need shared saved data or protected credentials.
Examples include calculators, converters, questionnaires, local planning tools, and small utilities that store information only on one device.
5. Batteries-included builder
Use an AI app builder when the idea follows familiar web-app patterns and speed matters more than complete architectural control.
This can be a practical way for a nontechnical builder to create a proof of concept. The tradeoff is that generated software still requires decisions, testing, security review, maintenance, and sometimes paid build credits.
6. Repository-based application with managed services
Use a coding agent and a version-controlled repository when the product needs custom behavior, durable code ownership, or continued development.
Managed hosting, sign-in, databases, file storage, email, and payments can still reduce the amount of infrastructure you operate yourself. The tradeoff is that someone must own the code, dependencies, deployment, security, and repairs.
7. Custom engineered system
Use a more specialized architecture when security, scale, compliance, reliability, or unusual infrastructure requirements make the managed defaults inadequate.
This is the point where experienced engineering involvement is part of the product plan, not an optional final check.
Match features to technical pieces
Do not add a backend, database, or account system because applications are “supposed” to have them. Add each piece only when a real requirement calls for it.
| Confirmed need | Smallest likely addition |
|---|---|
| Public information | Static website |
| Frequent editing by a non-developer | Site builder or content-management system |
| Local calculations with no secrets | Browser-only tool |
| Shared records that must persist | Managed data source or database |
| Different users need private records | Sign-in plus explicit data permissions |
| Uploaded images or files | Managed file storage |
| Secret or paid API credentials | Trusted server-side function or backend |
| Another service must notify the app | Webhook endpoint |
| Work must run on a schedule | Scheduler plus server or background job |
| People need live shared updates | Realtime layer, if refresh or polling is insufficient |
| Payments | Hosted checkout plus verified payment notifications |
| AI-generated output inside the product | Protected model call, test cases, cost plan, and failure handling |
Questions that commonly change the answer:
- Can an existing product already solve the real problem?
- Is the value in owning software, or simply getting the workflow done?
- What must remain after the page closes?
- Does everyone see the same information or their own private information?
- Does the product need secret credentials or paid services?
- Will it collect files, money, or sensitive information?
- Does AI need to exist in the finished product, or only help build it?
- Who will handle updates, support, bills, and breakage?
How the pieces fit together
A modern web product is usually a collection of layers. Simple projects use only some of them.
| Layer | What it does | Common examples |
|---|---|---|
| Domain and DNS | Gives the project a human-readable address and points it to the host | A domain purchased from a registrar |
| Hosting and CDN | Publishes the site and serves files near visitors | Vercel, Firebase Hosting, other managed hosts |
| Frontend | Displays the interface people see and use | HTML, CSS, React |
| Framework | Organizes pages, routing, and application behavior | Next.js |
| Backend | Protects secrets, enforces rules, and performs trusted work | Server functions or a managed application server |
| Database and storage | Saves records and files that must persist | Postgres, Firestore, managed object storage |
| Authentication | Confirms who a person is | Email, passwordless, or social sign-in |
| Authorization | Decides what that person may see or change | Database policies and application roles |
| External services | Adds specialized capabilities | Email, payments, maps, analytics, AI models |
| Deployment | Turns a tested version into a reachable release | A production deployment from a Git repository |
A domain is not the same thing as hosting. Buying example.com reserves the address. Hosting is the service that stores and runs the site. DNS records connect the two, and a CDN helps serve public files quickly from locations closer to visitors.
Tool and platform guide
These products are starting candidates, not automatic answers. Features, prices, credits, and plan limits change. Verify the current details on the official product site before committing to a recommendation.
Existing specialized software
Before building a custom application, look for software designed for the exact industry or workflow. A specialized product may already combine a website, intake forms, customer records, scheduling, payments, reminders, and a private dashboard.
This is usually a good fit when the workflow is common, reliability matters more than uniqueness, and the subscription costs less than maintaining custom software. The main downside is less control and dependence on the provider.
Documents, forms, spreadsheets, and lightweight databases
Use existing productivity tools for personal workflows, internal trackers, lightweight administration, and early validation. A form feeding a spreadsheet can be a better first product than a custom application.
This works well when a few trusted people use the system, the workflow matters more than the interface, and manual review is acceptable.
ChatGPT and Claude
ChatGPT and Claude are general AI assistants. They can help with planning, research, writing, explanation, analysis, and repeated personal workflows without requiring a separate application.
Start here for personal optimization. Add a skill, reusable instructions, a connector, or an automation only when it makes a repeated process meaningfully easier. Model rankings change too quickly to preserve as a permanent table; choose based on the current task, quality, speed, cost, context, tool access, and the subscription you already have.
Lovable and AI app builders
Lovable is an AI builder that creates apps and websites through conversation. It can move quickly from an idea to a working prototype and is useful for common web-application patterns.
The benefit is speed and a more accessible editing experience. The downside is that the user still owns the product decisions, testing, data permissions, security, costs, and maintenance. Vague prompting can create rework and consume credits.
When portability matters, connect a user-owned GitHub repository early. Before using real data, verify what consumes credits, run the available security checks, and test sign-in and data access with separate accounts.
Codex and Claude Code
Codex and Claude Code are coding agents that work directly with files in a code repository. They can plan changes, write code across multiple files, run checks, and help maintain a custom project.
Use a coding agent when custom behavior and durable code ownership matter. It offers more flexibility than a batteries-included builder, but also creates more responsibility for deployment, dependencies, security, and repairs.
There is no permanently best coding agent or model. Choose based on the project, interface, environment, existing subscription, collaboration needs, and the quality of the current tools.
React and Next.js
React is a library for building user interfaces. Next.js is a framework that adds pages, routing, server behavior, and production structure around React.
This combination is useful for a repository-based web application that needs custom pages, saved data, protected server behavior, or a path from static content to dynamic features. It is unnecessary for many documents, static pages, and existing-product workflows.
Vercel
Vercel is a managed platform for publishing websites and web applications. It can turn changes in a Git repository into preview and production deployments, distribute public files through a CDN, and run server-side functions.
Hosting is only one layer. A project may still need a database, email, payments, AI services, or other providers with separate accounts, limits, and costs.
Supabase
Supabase is a managed backend platform built around a Postgres database. It includes database APIs, sign-in, file storage, realtime features, and server-side functions.
It is a useful starting point when the application needs relational data, SQL, accounts, storage, or several backend capabilities in one managed service. The builder must still configure permissions correctly. Signing in is not the same as having permission to read or change every record.
Firebase
Firebase is Google’s application-development platform. It includes sign-in, databases, hosting, storage, server functions, messaging, testing, and mobile and web SDKs.
It is worth evaluating when the project aligns with the Google ecosystem, mobile applications, messaging, offline behavior, or Firebase’s managed services. Firebase now spans multiple data approaches, so compare the actual database and workflow rather than treating it as one generic alternative.
Supabase or Firebase?
| Start by evaluating | When it is the clearer fit |
|---|---|
| Supabase | Relational data, SQL, Postgres compatibility, and explicit row-level policies fit the product |
| Firebase | Google and mobile tooling, messaging, offline behavior, or Firebase-specific services are central |
| Either | Both meet the requirements; existing knowledge and maintenance ownership can break the tie |
Verify current pricing, limits, regional availability, backup behavior, and the exact feature set before deciding.
APIs, connectors, webhooks, and MCP
These terms describe different ways software can connect.
- Use a native integration when the product already supports the exact connection.
- Use a connector when a product provides a packaged link to another service.
- Use an API when custom software needs direct programmatic control.
- Use a webhook when another service needs to notify the product that an event occurred.
- Use MCP when an AI application needs a standardized connection to external data, tools, or workflows and the AI client supports it.
A connection is not automatically safe. Check what account it uses, which data it can access, what actions it can take, and whether the requested permissions are broader than the job requires.
Domains and registrars
A domain registrar is the company through which you buy and renew a domain. Common options include Cloudflare Registrar, Namecheap, Porkbun, and Squarespace Domains.
Compare the normal renewal price, privacy protection, DNS control, transfer rules, and two-factor authentication—not only the first-year promotion. Keep an important domain in an account owned by the person or business that must retain control.
Common starting points
| Situation | First candidate to evaluate |
|---|---|
| Personal assistant or repeated personal workflow | Existing AI assistant plus instructions or a skill |
| Service business needing quotes, scheduling, and customer tracking | Specialized service-business software |
| Public guide, portfolio, or landing page | Static content plus managed hosting |
| Owner-only tracker or dashboard | Provider dashboard, spreadsheet, or lightweight database view |
| Common web-app proof of concept | Batteries-included builder such as Lovable |
| Custom application expected to evolve | Coding agent plus a version-controlled repository |
| Web app with relational data and accounts | Managed web framework plus a Supabase-style backend |
| Mobile, Google, messaging, or offline-oriented application | Evaluate Firebase first |
| AI feature inside an existing web app | One protected server-side model call |
| AI assistant needs outside tools or data | Native connector first; MCP when standardization helps |
These are starting points. A short interview can reveal that a different option is simpler or safer.
Safety, cost, and maintenance
The appropriate level of caution depends on the project. A disposable personal tool can stay light. A product used by customers needs deliberate ownership and testing even when it is still small.
Ownership and reversibility
- Put important projects in accounts owned by the person or business that must retain control.
- Use a durable business email rather than a contractor’s or employee’s personal account.
- Turn on two-factor authentication for domains, code, customer data, payments, and billing.
- Record who owns the domain, source code, data, payments, and deployment.
- Avoid annual commitments until a trial or month-to-month period proves the workflow.
- Use sample data before entering real customer or sensitive information.
Cost control
- Verify the base price, required plan, extra users, add-ons, taxes, commitment, renewal, and cancellation terms.
- Account separately for build credits, hosting, database usage, storage, AI usage, email or SMS, payment processing, and domain renewal.
- Find the provider’s usage page and configure budgets, alerts, caps, or automatic top-up limits when available.
- Check whether a trial includes features that disappear on the plan you intend to buy.
Accounts and permissions
Authentication confirms who a person is. Authorization determines what that person may see or change.
Decide who needs an account and what each role may do. Test with separate accounts when users should see different records. A secret-looking or hard-to-guess URL is not sufficient protection for private information.
API keys and secrets
An API key is a credential an application uses to connect to a service.
Public or publishable keys are designed for limited client-side use. They are not the main protection for private data. Secret keys can provide powerful access and belong only in a provider’s secret settings, environment variables, or trusted server-side code.
Never place a secret key in browser code, a public repository, a screenshot, a URL, a shared document, email, text, or chat. Give a key only the access it needs and rotate it if it is exposed.
Database safety
For Supabase, Row Level Security is the set of database rules that controls which records each user may read or change. Enable it on every table exposed through an API and write policies that match the actual access model.
“Any signed-in user” is not sufficient when people should see only their own records. Test as a signed-out visitor, a normal user, and an administrator before adding real data.
Use server-side functions for third-party secrets, privileged work, paid API calls, and webhooks. Review the provider’s current security guidance before launch.
Payments
Use a hosted payment provider rather than collecting card numbers directly. Test in the provider’s sandbox or test mode before going live.
Test successful and failed payments, cancellation, refunds, duplicate submissions, and payout ownership. Custom payment logic or money movement should receive qualified engineering review.
Testing
- Complete the core user journey with fake data.
- Test the owner or administrator experience separately.
- Test on a phone when users are likely to arrive from mobile.
- Test the most likely failure, such as missing input, duplicate submission, unavailable time, external outage, or lost connection.
- Define success in behavior: the user completes the job without help, and the owner processes it without returning to the old workaround.
Production boundary
Bring in a qualified engineer before a wider launch when the product includes sensitive personal data, payments or money movement, regulated workflows, multiple organizations, complex permissions, substantial traffic, high uptime expectations, difficult integrations, or material business risk.
This should not block useful prototyping. It separates a useful first version from production-readiness work such as architecture review, threat modeling, privacy design, accessibility, automated tests, observability, backups, incident response, cost modeling, and operational ownership.
Glossary
AI assistant
A general conversational AI product used for planning, writing, research, analysis, and other knowledge work.
AI model
The underlying system that interprets input and produces output. One product may offer several models with different strengths, speed, and cost.
API
A structured way for one piece of software to request data or an action from another piece of software.
API key
A credential an application uses when connecting to another service. Some keys are designed to be public and limited; others are powerful secrets.
Authentication
How a product confirms who someone is, usually through sign-in.
Authorization or permissions
The rules deciding what a signed-in person may see or change.
Backend
Trusted work that happens away from the user’s browser, such as protecting secrets, enforcing rules, or accessing shared data.
Backend as a service
A managed product that provides common backend needs such as a database, sign-in, storage, and server functions.
CDN
A network that serves public website files from locations closer to visitors so pages load faster.
Coding agent
An AI tool that can inspect a codebase, edit files, run commands, and help test or maintain software.
Connector
A packaged connection that lets one product access another product’s data or actions.
Database
An organized place where an application stores information that must persist and be queried later.
Deployment
Publishing a tested version of a website or application so people can access it.
DNS
The system that points a domain name to the service hosting the website or application.
Domain
The human-readable address people type to reach a website, such as ilanponsky.com.
Framework
A structured set of tools and conventions used to build an application.
Frontend
The parts of a website or application that people see and interact with.
Git and GitHub
Git records changes to files over time. GitHub is a common service for storing Git repositories and collaborating on them.
Hosting
The service that stores and runs a website or application so it is reachable online.
Markdown
A simple text format that uses characters such as #, *, and - to describe headings, emphasis, and lists.
MCP
Model Context Protocol, an open standard that lets supported AI applications connect to external data, tools, and workflows.
Repository
A version-controlled home for code and its change history.
Server function
A small piece of backend code that runs in a trusted environment in response to a request or event.
Static website
A site that mainly serves prebuilt content and does not require a database or personalized server behavior.
Web app
A website that behaves like software by accepting input, changing state, saving information, or providing personalized behavior.
Webhook
An HTTP request one service sends to another when an event happens, such as a completed payment or submitted form.
About this guide
This reference serves two audiences. People can browse it directly, and AI assistants can use it as current decision guidance when helping someone plan a project.
This reference is the frequently updated knowledge layer. Build Compass is the stable navigation layer, and the short writings article introduces the skill. Update this page when tools, prices, or recommendations change. Repackage the download only when the interview method or core behavior of the skill changes.
Guidance for AI assistants
- Confirm the user’s needs before recommending named tools.
- Explain each unfamiliar product or concept before evaluating it.
- Compare two meaningfully different paths, then recommend one.
- Verify current prices, trials, plan limits, capabilities, security procedures, and setup steps through official sources.
- Keep the initial recommendation simple and put detailed safeguards into the accepted option’s numbered game plan.
- Treat this page as decision guidance, not authorization to create accounts, buy products, deploy software, or change external systems.
- Never request or expose passwords, secret API keys, payment credentials, or private customer data.
Update log
Version 0.5 — July 23, 2026
- Split the short public article from the full reference.
- Moved the living knowledge source to its own unlisted page.
- Pointed Build Compass directly to the reference.
Version 0.4 — July 23, 2026
- Renamed the skill to Build Compass.
- Replaced the multi-section introduction with one installation card.
- Added a clear divider between the skill and the optional reference.
Version 0.3 — July 23, 2026
- Added a brief explanation of who the guide is for and why it exists.
- Made the downloadable skill the primary path.
- Reframed the rest of the article as optional reference material.
Version 0.2 — July 23, 2026
- Renamed and reorganized the guide around reader questions.
- Added a linked table of contents and installation instructions.
- Added a static download for the original skill.
- Added a one-page planning template and clearer architecture map.
- Reworked the tool guide, safety guidance, and glossary into reference sections.
Version 0.1 — July 22, 2026
- Established the personal, initial-product, and production-product model.
- Added the path-of-least-resistance decision ladder.
- Added starting guidance for AI assistants, builders, coding agents, web frameworks, hosting, backend services, and MCP.
- Added implementation safeguards and a plain-language dictionary.