Workflow map
The current steps, owners, decisions, inputs, outputs, and failure points are documented before screens are built.
Access tier 03 · Custom Application
Customer requests and staff work in the same record.
Customer requests, staff access, files, job status, approvals, reports, and the next action attached to the same record.
Not sure which tier fits?
You do not need to choose one.
Tell me what customers or staff need to be able to do. I will recommend the smallest build that covers it.
Tell me what needs to work01 · Included
One workflow from request to record.
Use this tier when leads slip through, status lives in inboxes, or staff cannot see the current record. The first release follows one real job, request, customer, case, or project.
Intake
Collect the customer details, photos, files, selections, and consent needed to start with a complete request.
Shared records
Keep status, notes, files, dates, costs, owners, and the next action attached to the correct record.
Role access
Customers, staff, managers, and office users see the records and actions assigned to their role.
Portal and dashboard
Customers can send or read what they need. Staff can see queues, deadlines, exceptions, and current status.
Outputs
Notifications, documents, exports, reports, or outside connections are included when named in the first-release scope.
02 · Full details
Full Custom Application breakdown.
Open the list if you want to compare a common first release, optional workflows, and the public site layer.
At a glance3 common first-release pieces · 5 when needed · 1 public site layer Open full list
Showing 9 capabilities.
Common First Release
3 common
The records and views most businesses need first.
The proposal defines the first usable release instead of pretending every feature launches at once.
Custom CRM and customer history
Keep contacts, requests, source, status, notes, files, and the next action in one customer record.
- Lead and customer pipeline
- Searchable activity and ownership
New-customer intake
Collect the details needed to start without rebuilding the record from texts, email, and paper.
- Conditional questions and consent
- Photo, file, and document uploads
Dashboards, reports, and audit trail
See current work, overdue items, totals, exceptions, and who changed a record without rebuilding a report by hand.
- Filters, exports, and saved views
- Status history and accountable actions
When Scoped
5 options
Added when the workflow requires them.
The people, permissions, trigger, record, and result are named before each feature is built.
Customer portal and login
Customers can sign in to send information, review status, approve work, download files, or complete the next step.
- Private customer records
- Approvals, messages, and documents
Team login and role access
Office, staff, managers, and owners see the queues, records, and actions assigned to their role.
- Role-based permissions
- Assignment, status, and handoff controls
Bookings and Google Calendar
Availability, appointment types, staff calendars, reminders, and schedule changes can follow one named booking flow.
- Google or Microsoft calendar connection
- Booking status and reminders
Products, payments, and orders
Sell products or services, collect deposits, record payment status, and attach the transaction to the customer or job.
- Catalog or service selection
- Checkout, invoice, or payment-provider connection
Automations and integrations
A named record change can send a message, create a task, update another system, or prepare the next document.
- Email, SMS, and internal alerts
- Accounting, calendar, CRM, or vendor APIs
Public Site Layer
Paired tier
The public website stays separate.
It can share branding and connect to the application without exposing private records.
Website, proof, branding, and SEO
The application can be paired with a Business Site for public services, finished work, team profiles, products, and search pages. Private records stay out of search.
- Public pages and search foundation
- Private application behind login
03 · Boundaries
What is in the first release—and what is not.
A useful application has a defined first job. It does not try to replace every system, import every old record, and automate every exception at launch.
Commonly included
- Review of the current workflow and source tools
- A written first-release scope and role map
- Secure sign-in and the roles named in scope
- Intake, shared records, files, notes, status, and search
- Customer portal or staff dashboard screens named in scope
- Testing, deployment, and a recorded handoff
Separate scope when needed
- Cleaning or importing large amounts of historical data
- Accounting, payroll, payment, calendar, or vendor integrations
- Native iPhone or Android applications
- Hardware, field devices, barcode equipment, or offline operation
- New modules and roles outside the approved first release
- Third-party subscriptions, usage fees, and transaction costs
04 · Build
Start with the spreadsheet, inbox, and handoffs.
Walk through one record
Show how a real request enters the business, who touches it, what changes, and how it closes.
Approve the first release
The proposal names the roles, records, screens, actions, integrations, boundaries, and price.
Use working screens
The application is reviewed with realistic records and the people who will perform the steps.
Launch with a handoff
Access, critical paths, data boundaries, and recovery steps are checked and recorded before launch.
05 · Price
The price follows the first release.
Projects start at $4,500A focused first release with a defined workflow, roles, records, and screens can begin here.
What raises the priceMore roles, complex permissions, data migration, documents, reports, outside integrations, offline requirements, and additional workflows.
Before work startsThe proposal states the first-release boundary, included systems, review points, price, and what becomes a later release.
Records and accessYour business records remain yours. The approved role map controls who can see and change them.
Ongoing operationHosting, support, vendor services, and future releases are named separately when the application needs them.