Start with the work, not a feature list.
An idea such as “we need a leave-approval app” is a useful start. But it does not yet tell a developer who approves requests, which rules apply, or what happens when something goes wrong.
AlphaTales helps you work through those details in stages. Your team supplies the business knowledge, reviews what AlphaTales produces, and confirms the decisions along the way.
One example throughout: a team replacing leave requests in email with an internal application. All example details below are fictional.
01 / ESTABLISH THE CONTEXT
Introduce your organization.
Begin with guided onboarding. You can provide your organization’s website or enter its details yourself. Review the company profile, then answer basic questions about the team and how it works. If you do not know an answer, you can leave it for later.
Organization Context is the wider home for your business processes, departments, systems, and standards. The right people can complete areas such as ownership, security, data governance, and technology choices. Basic onboarding and detailed organization setup serve different purposes.
What moves forward: a shared business and technical starting point for your projects.
02 / DEFINE THE PROJECT
Describe the idea. Review what AlphaTales understood.
Create an internal application project with a name, description, and where people will use it. Add what you already know about the goal, users, main tasks, connected systems, rules, and intended outcome. A supporting document can provide more background.
Project Foundation Review organizes that information into five areas. You can correct the draft, add missing details, and confirm each area before moving into research.
- Business Problem & Outcome
- The problem to solve and what a useful result looks like.
- Users & Responsibilities
- Who is involved and what each person does.
- Core Work & Handoffs
- The work to complete and where responsibility changes hands.
- Core Capabilities
- What the application must enable people to do.
- Data, Systems & Rules
- The information, integrations, permissions, and operating rules.
Your review matters: an AI-generated statement can be incomplete or based on an assumption. Confirm it because it is correct for your business, not simply because it appears in the draft.
03 / WORK THROUGH THE UNKNOWNS
Answer the questions that shape the plan.
The project can include a Quick project check before Deep Research. These clarification questions help fill gaps in the available information. Review the questions and supply what your team knows; a missing business decision should remain visible rather than becoming an unnoticed guess.
Deep Research examines the project’s business context, current process, risks, and opportunities. Check those findings against how your organization actually works. The research then feeds the first application workflow draft.
Here is why a small clarification matters. “Managers approve leave” sounds complete until a manager submits their own request.
Choose an answer to see what it means for this fictional plan. This example does not change your AlphaTales account.
The plan says managers approve leave, but it does not yet say who approves a manager’s own request.
Why it matters: the developer needs to know who can see and act on this request.
What moves forward: research findings and clearer decisions for the workflow. Read the research guide →
04 / REVIEW HOW THE APP WILL WORK
Connect the people, steps, and rules.
Application Workflow turns the planning context and research into a draft of the work the application needs to support. Review the workflow groups and individual flows, including the roles, decisions, and exceptions. Confirm the scope after checking it with the people who do the work.
Fictional leave request. Your actions stay in this example.
- SubmitEmployee sends a request
- ReviewAn approver checks it
- RecordKeep the decision history
- NotifyEmployee receives the result
- Requested by
- Alex · Employee
- Duration
- 2 working days
- Reviewer
- Manager
Draft · ready to submit
Start with an employee’s request.
Try the normal path, or see what happens when the manager is unavailable.
Each action needs a rule: who can do it, what gets recorded, and what happens next. That is what your team reviews in Application Workflow.
What moves forward: a reviewed description of how the application should behave. Explore the workflow guide →
05 / PREPARE THE BUILD PLAN
Define the features and technical direction.
Use the confirmed workflow to create or generate features. Review what each feature should do and agree on the first version. This is where the process becomes specific work for the application: the request form, the approval queue, and the decision history in our example.
Then review the architecture and technology choices against the project’s needs and your team’s standards. The people who will build and run the application should check this direction before it becomes part of the handoff.
Our example starts with submitting, reviewing, and recording leave requests. Payroll integration stays outside the first version unless the team agrees it is needed.
What moves forward: selected feature specifications and a reviewed technical direction.
06 / HAND OVER THE CONTEXT
Give development the plan behind the idea.
Select the application workflows, features, and architecture for the Dev Pack. Your development team can use the downloaded planning material, or supported coding tools can access project context through MCP.
The handoff connects the intended behavior to the decisions behind it. Your developers or AI coding tools then implement the application. Your team still needs to review the code, test the software, and check that it meets the agreed requirements.
The result: a reviewed plan for implementation. Read the Dev Pack guide →
Before you start
Do I need a complete specification first?
No. Start with the problem and the information you have. The creation form lets you add more context, and the review stages help your team work through missing details. You still need people who can answer the business questions.
Does AlphaTales build the finished application?
This journey prepares the plan and development context. Developers or connected AI coding tools carry out implementation. Planning does not replace code review, testing, or your team’s approval.
Can I use this page as a setup guide?
This page explains the overall journey. For the steps inside the app, use the internal app getting-started guide.