Multiple roles
Different people need different permissions, records, screens, and actions.
Custom software · Scoped after discovery
Build the business tool standard software cannot provide.
Custom application work starts when your business needs specific roles, records, calculations, screens, or integrations that the defined website and workflow offers cannot cover.
01 · What I build
Software built for a job standard tools cannot handle.
One or more of these needs must be central to the first release. Standard forms, booking, CRM, and routine workflow rules belong in the defined offers instead.
Business-specific records
The information and relationships do not fit a standard CRM, portal, or project tool.
Proprietary calculations
Pricing, estimating, scoring, scheduling, or decision logic is specific to the business.
Complex integrations
Several systems must exchange controlled records, states, and exceptions.
Purpose-built interfaces
The business needs an operational workspace, not another generic form or dashboard.
Defined transition
Permissions, data ownership, recovery, operating costs, and exit need their own written plan.
02 · Written scope
Know what will be built before development starts.
The specification states what gets built, what it costs, how you will review it, and what belongs in a later release.
The first release includes
- The business problem and current process
- The people and roles using the system
- The records, screens, and actions included
- The outside systems that need to connect
- The review points and launch checks
- The build price and operating costs
- The existing capabilities that are not being billed again
Add in a later release if needed
- Additional roles, modules, or workflows
- Large historical data cleanup or migration
- Complex vendor and accounting connections
- Native iPhone or Android applications
- Hardware or offline field operation
- Third-party vendor licensing and transaction fees
- Standard website, lead, booking, or workflow work covered by another offer
03 · Process
Start with one real example.
Walk through the work
Show how one real request enters, who touches it, what changes, and how it closes.
Approve the specification
You get the first-release boundary, features, review points, costs, and operating needs in writing.
Use working screens
You review the real system with realistic records instead of approving a slide deck.
Launch with a handoff
Access, critical paths, data boundaries, and recovery steps are checked and recorded.
04 · Scope
How custom application scope works.
Start with a useful first releaseThe written scope defines the development work.
Before work startsYou receive a written specification stating what gets built, what it costs, and what sits outside the first release.
Software license + system managementThe contract lists the license separately from the hosting, monitoring, maintenance, support, vendor services, and management needed to keep the application working.