How to Build a Legal Case Intake App in 48 Hours (US-Focused)

Case intake is the front-door workflow that captures a new legal inquiry, qualifies it, checks for conflicts, routes it to the right person, and records a decision (accept, decline, refer, or request more info). It is not just a web form, it is a tracked, auditable process that connects marketing, intake, attorneys, and ops to matter creation and follow-up.

TL;DR

• Treat intake as a workflow: capture, qualify, check conflicts, route, decide, and log outcomes.
• Start with one high-volume workflow (new client inquiry) before adding referrals, existing-client requests, or compliance intakes.
• Build the minimum viable intake app around roles, routing rules, and an audit trail, not fancy UI.
• Use integrations only where they reduce retyping (email, calendar, CRM, case management), otherwise keep v1 simple.
• Choose build vs buy based on how often your rules change, how many roles touch intake, and how much visibility you need.

Who this is for: Legal ops leads, managing partners, and intake managers at US SMB and mid-market firms who need a consistent, trackable intake process.

When this matters: When leads are slipping through the cracks, conflict checks are manual, or you cannot explain intake-to-client conversion by source, practice area, or reviewer.

Most law firms do not lose potential matters because they lack leads. They lose them because case intake is scattered: a web form here, a shared inbox there, sticky notes, hallway conversations, and a spreadsheet no one trusts. In the US market, that mess quickly turns into real risk: inconsistent conflict checks, unclear follow-up ownership, and no reliable record of why a matter was accepted or declined. A case intake app fixes this by turning intake into a single workflow with roles, routing, and an audit trail. The goal is not to “digitize a form.” The goal is to make it hard to drop the ball and easy to see what is happening. This guide walks through what case intake should include, which legal workflows to start with, and how to ship a production-ready v1 in 48 hours using a no-code platform like AltStack, then iterate safely as your rules evolve.

Case intake is a workflow, not a form

A form collects information. Case intake makes decisions with that information and proves those decisions happened. In a legal context, “good” intake usually means you can answer, quickly and consistently: Who is this? What do they want? Is there a conflict? Is it in-scope for us? Who is responsible for the next step? What did we decide, and when? That is why intake systems fail when they are treated as a static questionnaire. Legal intake needs routing, statuses, deadlines, and permissioning, because multiple roles touch the same request and the stakes are higher than a typical sales lead.

What triggers a rebuild of intake for US legal teams

The tipping point is rarely “we want automation.” It is usually one of these operational failures: You cannot tell which inquiries are waiting on you versus someone else. A shared inbox hides accountability. A conflict check is performed inconsistently, or documented inconsistently, depending on who is on intake duty. Different practice areas ask different questions, so staff improvise, and you end up with missing facts when attorneys review. Follow-up is manual and uneven: the firm responds quickly to some sources and slowly to others. You cannot explain outcomes: which channels produce qualified matters, which decline reasons are most common, and where handoffs break. If any of those sound familiar, treat intake as an internal tool, not a marketing asset. That framing changes what you build first: workflow clarity and visibility before bells and whistles.

The minimum viable case intake app: what it must do on day one

A v1 intake app should feel boring in the best way. It should reliably capture the right information, move work to the right person, and produce a clean record. Here is the minimum set of capabilities most US legal teams need before they add anything else. If you want a concrete starting list of fields and rules, use a template of intake fields, rules, and notifications as your baseline and tailor it by practice area.

• Intake record with statuses: New, In Review, Needs More Info, Conflict Check, Scheduled, Accepted, Declined, Referred, Closed.
• Role-based access: intake staff can edit, attorneys can review and decide, admins can manage fields and routing.
• Structured data capture: contact info, matter type, jurisdiction, opposing parties, key dates, urgency, how they found you.
• Conflict check workflow: capture parties, run your internal check process, record result, require a decision before acceptance.
• Routing rules: assign by practice area, location, language, priority, or source; include fallback queues.
• Tasking and reminders: follow-up tasks with due dates; escalation when an item sits too long.
• Audit trail: who changed what status, when the decision happened, and who approved it.
• Reporting view: pipeline by status, source, practice area, assignee, and outcome reason.

Start with one workflow that is high-volume and easy to define

If you try to model every intake path at once, you will stall in edge cases. The faster approach is to pick one workflow that happens frequently and has clear rules, ship it, then expand. Good “first workflows” in legal tend to be: New client inquiry to consultation scheduled. Existing client request (often routed to an assigned attorney or matter owner). Referral intake (usually simpler, but needs tracking and follow-up). If you need a way to visualize handoffs and automation points before you build, start with a full case intake process map and mark where decisions are made today versus where you want them to be made.

Build vs buy: the decision comes down to change, not features

Many intake products look similar in demos: forms, pipelines, reminders. The practical difference shows up six weeks later, when your team wants to change the rules. Buying tends to work when your intake process is stable, you can live with the vendor’s workflow model, and you mainly need a packaged system with support. Building tends to win when your firm’s intake rules change often, multiple practice areas have different qualification logic, or you need tighter control over permissions, routing, and reporting. It also helps when intake must integrate into the tools you already use, without forcing staff to retype the same information in three places. If you are actively comparing options, best tools for case intake and when to build your own is a useful way to pressure-test what “buy” gets you versus what you will still end up customizing around.

A practical 48-hour build plan (what to do, in order)

“48 hours” is realistic for a v1 if you cut scope aggressively and focus on workflow and data. The output you want at the end is a working app in production with real users, not a prototype. Below is a sequence that works well with AltStack because you can generate a starting app from a prompt, then refine with drag-and-drop, add role-based access, and deploy without hand-coding.

• Hour 0 to 2: Define the workflow boundaries. Pick one intake path. Define statuses, the decision-makers, and what “done” means.
• Hour 2 to 6: Draft your data model. List the fields you need for qualification and conflicts. Mark which are required and which are conditional.
• Hour 6 to 12: Generate the first version of the app. Create intake submission, review queue, attorney decision screen, and an admin panel for fields and routing.
• Hour 12 to 20: Add routing and permissions. Implement assignment rules, escalation, and role-based access so only the right people see sensitive items.
• Hour 20 to 28: Wire in the notifications you actually use. Email or internal notifications for new intake, reassignment, and items stuck in review.
• Hour 28 to 36: Create dashboards for the questions leadership will ask. Volume by source, conversion to consult, decline reasons, time-in-status by assignee.
• Hour 36 to 44: Test with real scenarios. Run through: clean accept, clean decline, conflict discovered late, missing info, wrong practice area.
• Hour 44 to 48: Launch v1 and set a feedback loop. Start with a small group, capture change requests, and schedule a weekly iteration slot.

What to measure so intake becomes an operating system, not a black box

If you only measure “number of inquiries,” you will optimize for noise. The metrics that actually change behavior are the ones that expose bottlenecks and decision quality. Start with: Time in status (especially New and In Review). Consultation scheduled rate (by source and practice area). Decline and referral reasons (so you can adjust marketing and qualification). Workload by assignee (to balance coverage and avoid invisible queues). Conflict check outcomes and turnaround (to reduce risky shortcuts). A good case intake dashboard turns leadership questions into filters, not meetings. When people can self-serve the answer, the process improves faster.

Common mistakes that slow teams down

• Trying to capture every edge case in v1, instead of shipping one workflow and iterating.
• Building a long intake form without a decision workflow, routing rules, or ownership.
• Letting conflicts be a separate, untracked step outside the intake record.
• Over-integrating early, then getting blocked on API access or data mapping before users see value.
• No decline reasons, no time-in-status tracking, and no way to diagnose bottlenecks.
• Treating intake as a marketing problem, when it is really an operations and risk-control problem.

Where AltStack fits for legal case intake

AltStack is a good fit when you want a custom case intake workflow without turning it into a software project. Teams typically use it to generate a starting intake app from a prompt, then tune the workflow with drag-and-drop, add role-based access, connect to existing tools, and deploy a production-ready internal tool or portal. If your firm also handles adjacent intake processes, like compliance requests, it can be helpful to standardize the “front door” patterns. See best tools for compliance intake and how to build your own to reuse the same thinking across workflows. If you want to explore the build approach without committing, map your current intake path, pick one workflow, and prototype the screens and statuses. You will learn quickly whether your pain is mostly about UI, ownership, or decision logic. Most firms discover it is decision logic, which is exactly where a customizable case intake app pays off.

Common Mistakes

• Over-scoping v1 to include every practice area and edge case.
• Capturing data without defining who decides and what the statuses mean.
• Routing by “whoever is available” with no fallback queue or escalation.
• Running conflict checks outside the system with no recorded outcome.
• Launching without dashboards, then guessing where the bottlenecks are.

Recommended Next Steps

1. Pick one intake workflow to standardize first (usually new client inquiry).
2. Write down your statuses, decision makers, and routing rules on one page.
3. Use an intake field template and remove anything you will not act on.
4. Build and launch a v1, then schedule weekly iteration time for the first month.
5. Add integrations after the workflow is stable and your data model is proven.

Frequently Asked Questions

What is case intake in a legal setting?

Case intake is the workflow that turns a new inquiry into a documented decision. It captures the right facts, runs qualification and conflict checks, routes the request to the right reviewer, and records outcomes like accepted, declined, referred, or needs more info. In practice, it is a tracked process with statuses and ownership, not just a form.

How is a case intake app different from a simple intake form?

A form collects information once. A case intake app manages the work after submission: queues, assignments, internal notes, conflict check steps, approvals, reminders, and an audit trail. It also produces reporting, so you can see volume, time-to-response, and outcomes by source, practice area, and reviewer.

Can we really build a legal case intake app in 48 hours?

You can ship a useful v1 in 48 hours if you limit scope to one workflow and focus on the essentials: statuses, roles, routing, conflict check documentation, and dashboards. The goal is a production-ready first version that real users can run, then you iterate based on actual intake behavior and change requests.

What fields should a legal intake workflow require?

At minimum: contact details, matter type, jurisdiction, key dates, a short description, and the parties needed for a conflict check (including potential opposing parties). Add conditional fields based on practice area, and avoid collecting details you will not use to qualify, route, or make a decision.

How do we handle conflict checks inside the intake process?

Treat conflict checks as a required stage with a recorded outcome. Capture party names early, route the intake to the appropriate reviewer, and block “accepted” status until the conflict check result is logged. Even if the actual conflict search happens in another system, the intake app should track who did it and when.

Should we buy intake software or build our own?

Buy when your process is stable and you can live with the vendor’s workflow model. Build when your routing rules change often, multiple practice areas need different qualification logic, or you need tighter control over permissions and reporting. The deciding factor is usually how frequently you expect to modify fields, roles, and decision rules.

What should we measure to improve intake performance?

Track time in status (especially from new inquiry to first response), consultation scheduled rate, decline and referral reasons, workload by assignee, and conflict check turnaround. These metrics help you find bottlenecks, balance coverage, and improve decision quality without relying on anecdotes from the shared inbox.