How to build an internal tool without a dev team

An internal tool succeeds when it removes ambiguity from one repeated job. Start with a single workflow, name the record that moves through it, define who can change each state, and only then describe screens. Use Plan when those decisions are unresolved. Use Build once the path and acceptance criteria are concrete.

Start with an interactive prototype using clearly labeled sample records. Use it to review the queue, request details, status changes, and validation. A role selector or a saved-looking screen in that prototype does not establish sign-in, shared storage, or access protection.

Then request the backend work as a separate, explicit step and verify it with separate user accounts. The operational target is one complete journey: create a record, review it, change its status, reload, and find the same saved result. This guide separates those two stages; it does not present a generated demo as a deployed operations system.

“Build an admin dashboard” is a visual request, not an operational specification. A useful internal tool begins with a sentence that has an actor, an object, a decision, and an outcome:

A support lead reviews refund requests, asks for missing evidence, approves or rejects each request, and exports the final decision for finance.

That sentence already suggests the primary record, the people involved, the states, and the handoff. Write the current process before imagining a new interface. Note where information enters, who checks it, what can block it, and what downstream system receives the outcome.

Choose a workflow that is repeated often enough to matter but narrow enough to observe end to end. “Run the company” is too broad. “Review weekly refund requests from intake to finance export” is testable. The right boundary usually has one primary record and one unambiguous completion event.

Capture five facts before generating:

1. Trigger: what starts the work?
2. Record: what information must survive between steps?
3. Decision: which fields or evidence determine the next state?
4. Owner: who is allowed to act at each point?
5. Done: what observable result closes the workflow?

This avoids a common failure mode: a polished dashboard with filters and charts that never resolves the actual handoff. Internal users tolerate plain visuals more readily than unclear ownership or lost work.

Translate the workflow into the smallest durable record that all roles understand. Use the terms your team already uses. Prefer explicit fields and a short list of states over clever abstractions.

Then define allowed transitions. A refund request might move from New to Needs review, Waiting for evidence, Approved, or Rejected. Decide whether a terminal decision can be reopened and who can do it. Do not invent twelve statuses because the interface can render them. Every state creates copy, filtering, permission, and test obligations.

Decide where the information will actually be saved. Sample data can prove the flow, but it cannot support a team or protect sensitive information. Before using real records, confirm that information is shared reliably, access is limited by role, important changes can be traced, and retention and deletion rules are clear.

A page list is easier to generate after the permission model is explicit. Start with a role matrix:

This table is a product promise, not proof that access is protected. The app must enforce the same rules even when someone opens a copied link or attempts an action they should not have. Test every sensitive action while signed in as each role; hiding an Admin button alone is not security.

Now derive screens from work:

• a queue that makes urgency and ownership visible;
• a record page that keeps evidence, status, and actions together;
• an intake form with validation and recovery;
• an admin surface only if role management is part of the first workflow;
• an audit or activity view if the team must explain who changed what.

Give each role a useful landing state. A requester may need “My requests”; a reviewer needs an ordered queue; an admin needs exceptions. One universal dashboard often hides the next action from everyone.

Use Mythos Plan to settle the workflow and access rules before changing source. Ask it to separate the frontend prototype from the backend work needed for real records. Approval starts a separate Build; the current Plan and Build credit rules explain the charges.

Paste a prompt like this:

Plan an internal refund-review tool for a 12-person operations team.

Primary workflow:
1. An operator creates a request with customer, amount, reason, and evidence.
2. A reviewer assigns it, asks for missing evidence, then approves or rejects it.
3. Finance exports approved decisions.

Roles:
- Requester: create and view own requests.
- Reviewer: view all requests, request evidence, approve, reject, export.
- Admin: reviewer abilities plus reopen decisions and manage roles.

Before proposing pages, identify:
- the minimum information each request must keep,
- the allowed status changes,
- what each role may see and do,
- empty/loading/error/success states,
- which parts need shared storage or an outside service.

Make the first deliverable a frontend prototype with labeled sample records.
List shared storage, authentication, authorization, and real exports as a
separate implementation stage. Do not add analytics or notifications.

Review the plan as an operator would. Can a new team member tell what “done” means? Does every sensitive action say who may use it and what happens when someone else tries? Are unresolved decisions visible? Edit the draft until those answers are clear, then approve it. Read how Plan works.

For a new project, make the first request explicitly about the interface and sample states. A frontend can demonstrate the job before any live system is connected:

Build the frontend prototype of the approved refund-review workflow.

Keep the existing visual style and preserve behavior outside this workflow.
Implement the queue, request detail, and intake form using realistic sample
records. Label the prototype and simulated actions clearly. Do not create
backend resources, connect providers, send refunds, or imply data is saved.

Acceptance:
- The reviewer can filter New, Waiting for evidence, Approved, and Rejected.
- Invalid intake data shows field-level errors without losing valid values.
- Provide labeled role previews so we can review each role's interface.
- Do not present those role previews as authentication or access protection.
- Empty, loading, error, and success states are deliberate.
- Desktop and mobile keep the primary action and status understandable.
- Unrelated pages, navigation, and styling remain unchanged.

Review the delivered prototype with the people doing the work. Once its fields, states, and role views are agreed, send a separate request to connect the required backend and implement real sign-in, record storage, role enforcement, and export. Name the provider and account you intend to use; review any permission or billing decision before accepting it. If a required connection is unavailable, keep the result labeled as a prototype.

The verification matrix below applies to that connected version. A sample-only preview can pass the layout and interaction checks, but it cannot pass the persistence or authorization checks. Building and editing explains delivery, while Credits and usage covers failed or stopped work.

Use realistic density. Test long names, missing optional information, a busy queue, and similar status labels. A layout that works with three perfect examples may fail during a real working day.

Turn the acceptance criteria into a checklist someone else can repeat. Record the app version, account role, input, expected result, and actual result. “Looks good” is not enough.

Keep sample records separate from real information. If shared storage is not connected, call the result an “interactive prototype with sample records,” not an “operations system.” If sign-in exists but role access has not been tested, the workflow is not ready for sensitive use.

Invite a small pilot group that performs the actual work. Give them a real but low-risk batch, a way to report blockers, and a clear fallback to the previous process. Watch for ambiguous ownership, missing context, irreversible actions, and work that disappears after refresh.

Before the pilot, name the system of record. If the new app is authoritative, define backup, export, retention, and recovery. If another system remains authoritative, define the synchronization or manual reconciliation step. “We will remember to copy it later” is not a control.

Track operational signals that describe the workflow rather than vanity:

• requests completed without leaving the tool;
• records returned for missing information;
• time spent waiting in each state;
• authorization or validation failures;
• manual reconciliations and duplicate entries.

Do not fabricate targets before observing a baseline. The first pilot exists to discover where the model and interface differ from the work. Make the next revision narrow: one named problem, preserved unrelated behavior, and a verification case that would have caught it.

A generated internal tool is a poor first move when the process itself has no owner, when decisions cannot be expressed consistently, or when the team is trying to automate a rare exception instead of a repeated path. Clarify operations first.

Do not place regulated, financial, health, or sensitive employee data into a candidate merely because the screens work. Production use may require security review, privacy and retention controls, vendor assessment, auditability, backup, disaster recovery, accessibility, and legal approval beyond the generated application.

Avoid replacing a stable commercial system when your only advantage is a different dashboard. Custom software creates ongoing ownership: dependencies, incidents, schema changes, integrations, and user support. Build when the workflow is differentiating or when the cost of the current process clearly justifies that responsibility.

Can I start from a spreadsheet?

Yes. Treat its columns, formulas, owners, and exception notes as evidence of the current workflow. Clean the concepts before copying the layout. A spreadsheet often combines data, permissions, and process in ways an app must separate.

Do I need a backend for the first version?

Not for a visual or interaction prototype. You do need durable shared storage for a multi-user operational system. Confirm persistence, authentication, authorization, backup, and export before treating it as the system of record.

Should I use Plan or go straight to Build?

Use Plan when roles, states, data boundaries, or scope are unresolved. Go straight to Build for a bounded change whose desired behavior and verification are already clear.

How many roles should version one have?

Use the smallest set that represents genuinely different authority. A dozen job titles may collapse into Requester, Reviewer, and Admin. Add a role only when it changes what a person can see or do.

How do I prevent the next revision from breaking the tool?

Name what must remain unchanged, make one coherent request, verify the affected workflow and its neighbors, and use version history if you need to compare or revert. The dedicated iteration guide provides a repeatable loop.

Is a passing generated Build safe for company-wide use?

No. A successful Build means Mythos completed its automated checks. It does not prove that your organization’s permissions, privacy, backups, compliance, or operating procedures are ready. Review those separately before a wider rollout.

This guide is grounded in the current Mythos product contract:

• Plan mode: read-only drafts, edits, approval, and cancellation
• Building and editing: candidate lifecycle and delivery states
• Writing good prompts: outcome, context, constraints, and acceptance
• Version history: inspect and revert without deleting later work
• Troubleshooting: how failed and interrupted Builds behave

Product, security, and operational requirements outside those documents are presented as review recommendations, not as Mythos guarantees.

Continue with:

• Plan vs Build in Mythos
• How to iterate without breaking the rest of your app
• From prompt to a production candidate