01
Current process
Show how the work happens now, including spreadsheets, forms, email handoffs, and workarounds.
Application planning guide
Bring the idea. We’ll help make the buildable version clear.
You do not need a technical specification or polished designs to start. Use this guide to describe the outcome, show the important workflow, identify what the app must connect to, and gather the decisions that shape scope, schedule, technology, and hosting.
Start here
Answer the first seven questions in plain English.
Expect about 20–30 minutes. Pick the closest answer, write “unknown” when needed, and only open the deeper sections that apply to your project.
01What are you building?Open question
Choose the closest description, then finish the sentence: “We are building ______ for ______ so they can ______.”
02Who uses it, and what is their most important job?Open question
Name the first user types—not every possible audience. Then describe the one job that makes the product valuable. A good answer is: “A successful user can ______ in ______ or fewer steps/minutes.”
03What should it look and feel like?Open question
Pick a direction and share examples. Screenshots, paper forms, spreadsheets, brand assets, or products you like are more useful than trying to name a design trend.
04What must it interact with?Open question
Name every system that should send or receive information. For each one, say whether data moves into the app, out of the app, or both—and whether the sync must be real-time.
05Where does it need to run?Open question
Choose the environments required at launch. Also flag whether the app needs camera, GPS, notifications, Bluetooth/NFC, background work, offline use, or a printer/scanner.
06Will there be logins, roles, or private data?Open question
Say whether access is public, individual, team-based, or role-based. Identify what each role can see or change, and flag financial, health, personal, location, children’s, or confidential business data.
07What is the first release, and when does it need to be ready?Open question
List the three capabilities that cannot be cut. Add the target date, whether a prototype is needed first, and which matters most: speed, cost, polish, flexibility, security, or scale.
Show the experience
Rough sketches are often enough.
Share a paper photo, marked-up screenshot, spreadsheet, PowerPoint slide, Figma board, or plain text. For each screen, label who uses it, what they are trying to do, and the main action.
USER JOURNEY
[Landing] → [Sign in] → [Dashboard]
↓
[Create record]
↓
[Review + Submit]
↓
[Confirmation]SCREEN NOTES
- Purpose: What is the user doing here?
- Information: What must be visible?
- Action: What should happen next?
- Failure: What should happen when it does not work?
What to gather
Bring the evidence behind the idea.
Missing information is fine. It simply becomes a visible discovery item instead of a hidden assumption.
02
Real examples
Bring three to five successful and unsuccessful examples with private information removed.
03
Design references
Share brand assets, screenshots, competitor links, reports, sample emails, and anything users already recognize.
04
Technical access
Identify system owners, API documentation, sandbox access, device models, and test data. Never send passwords or production secrets in a brief.
05
Business constraints
Name decision-makers, target date, budget range if known, support expectations, and any privacy, accessibility, or contracting requirements.
Evaluate the alternatives
Compare the workflow, not just the screenshots.
Test the same realistic task in three to five products. Include a spreadsheet or manual process as an alternative—it is often the real competitor.
Key job
Can a new user complete the important task without help? How long does it take?
Friction
Count clicks, duplicate entry, confusing labels, dead ends, and what happens when something fails.
Fit
Does it work on the devices, with the integrations, and for the permissions your users need?
Trust
Review support, security information, uptime, export options, accessibility, and recent user complaints.
Commercials
Record pricing, limits, setup cost, contracts, and which important features are behind a paywall.
Opportunity
Write one specific thing your product could make easier, faster, safer, or more understandable.
Hosting and scaling
Start managed. Scale with evidence.
For most new business apps, begin with managed hosting, a managed database, server-side secrets, backups, logs, error alerts, and separate development, staging, and production environments.
Managed web platform
A strong default for a web app or portal. Pair managed frontend hosting with a managed database, authentication, file storage, logs, and background jobs.
Tradeoff: Fast delivery, previews, lower operational burden.
Firebase + Cloud Run
A good fit when real-time data, authentication, push notifications, or the Google ecosystem matter. Use Functions or Cloud Run for server-side work.
Tradeoff: Convenient real-time and serverless building blocks; watch quotas, timeouts, and vendor coupling.
AWS, Google Cloud, or Azure
A good fit for private networking, enterprise procurement, unusual runtimes, regulated workloads, multi-region design, or an existing cloud operations team.
Tradeoff: Maximum control and breadth; more architecture and operations decisions.
Managed VPS
Reasonable for a small, predictable, cost-sensitive application when someone owns patching, backups, monitoring, failover, and incident response.
Tradeoff: Lower infrastructure cost can mean higher operational responsibility.
Technology choices
Choose the constraint, then the tool.
01
Phone-friendly web/PWA
Start here for forms, search, dashboards, content, accounts, and occasional device features. It is usually the fastest path to broad device coverage and simple updates.
02
Native or cross-platform mobile
Choose this when background work, Bluetooth/NFC, advanced camera features, deep offline behavior, sensors, or app-store distribution are central.
03
Relational database
Use it when records relate to one another, transactions matter, reporting is important, or accounting-like correctness is required.
04
Document or real-time database
Use it when flexible data shapes and live synchronization/offline behavior are more important than complex joins and reporting.
05
Queues and object storage
Use background jobs for slow exports, document generation, image processing, and third-party sync. Keep large files in object storage rather than ordinary database rows.
Useful references: PWA installability, React Native, QuickBooks API scopes, and Honor Tech security and vendor readiness.
What to expect from us
Clarity before commitment.
Discovery and scope. We turn the brief into user journeys, priorities, assumptions, risks, integration questions, and acceptance criteria.
UX and visual direction. We prototype the important flows, confirm the first release, and establish a visual direction before polishing every edge case.
Build and review. Working software arrives in reviewable increments, with decisions and limitations visible as the product takes shape.
QA, launch, and handoff. Expect testing of journeys, permissions, validation, error states, supported devices, integrations, deployment, backups, and the responsibilities that continue after launch.
Scope reality. Schedule is shaped by user journeys, data complexity, integrations, platforms, review cycles, and unknowns—not just the number of screens.
Ready-to-share brief
Copy this into your notes.
PROJECT NAME: ONE-SENTENCE OUTCOME: PRIMARY USERS: THE MOST IMPORTANT JOB: MUST-HAVE FEATURES FOR THE FIRST RELEASE: 1. 2. 3. FIRST USER JOURNEY: INTEGRATIONS + DATA DIRECTION: PLATFORMS AND DEVICES: LOGIN, ROLES, AND PERMISSIONS: DATA STORED + SENSITIVE DATA: SUCCESS MEASURE: TARGET DATE + TOP CONSTRAINT: KNOWN COMPETITORS OR ALTERNATIVES: WHAT IS STILL UNKNOWN:
A practical first step
Bring the workflow and the questions that matter.
A first conversation is enough to surface fit, risk, and the most useful next move—whether or not that move includes us.