Configure
- Use when
- The existing product already supports the states and permissions you need.
- Delivers
- Configured workflow, roles and automation.
- Watch
- Avoid forcing business rules into fields the platform cannot own safely.
CRM & SaaS Development
Build the workflow around durable state, not around screens.
CRM, portals and SaaS products are reliable when triggers, actors, permissions, records and exceptions are explicit. The dashboard is a view of the operating model—not the model itself.
Build choice
01
Configure
02
Integrate
03
Build
04
Replace
Architecture choice
Configure, integrate, build or replace?
Choose the smallest intervention that closes the business loop without creating a second source of truth.
Integrate
- Use when
- Two capable systems need to exchange durable context.
- Delivers
- Clear ownership, sync rules and failure handling.
- Watch
- Do not mirror every field in both directions.
Build
- Use when
- The workflow or state model is genuinely specific to the business.
- Delivers
- Custom product around explicit records and transitions.
- Watch
- Keep price, permission and completion authority deterministic.
Replace
- Use when
- The current core prevents safe change or creates irreconcilable state.
- Delivers
- Migration plan and bounded replacement.
- Watch
- Preserve data, history and rollback options.
State model
Define what the record means before drawing the dashboard.
A useful state has a trigger, an owner, an allowed next action and an exception path.
Created
The initiating event produced a durable record.
Next: Validate required context or reject the record.
Ready
The record has enough verified context for the next operation.
Next: Assign or execute the business action.
In progress
An operator or system owns the active work.
Next: Complete, pause or escalate.
Needs review
Automation or integration cannot safely decide the next state.
Next: Route to an accountable human or owning system.
Complete
The defined outcome and evidence exist.
Next: Close, report or start a new cycle.
Authority boundary
A workflow can be connected without giving every screen the same authority.
The customer interface, operator workspace and system of record can share context while still owning different decisions.
✓
The interface may collect intent; the authoritative service owns durable state.
✓
Pricing and eligibility come from explicit rules, not from UI defaults or model output.
✓
Operator overrides need a named permission and an audit trail when the workflow is consequential.
✓
A status shown to the customer should map to a real backend state rather than a decorative label.
From workflow to interface
Put roles and handoffs into practice.
Compare the client and owner views of one fictional project. See how a review becomes a clear next action, without connecting accounts or changing business records.
Acceptance example
An order appears “paid” in one screen but operations still treat it as pending.
This is not a UI inconsistency; it is an authority problem.
Name the authoritative payment event
The provider or approved operator owns payment confirmation—not a client-side flag.
Persist the commercial state
The order record stores the resulting state and the event that caused it.
Separate work state from payment state
Processing can be blocked, queued or cancelled without rewriting payment history.
Exception / boundary
If the workflow is simple and the existing CRM already models it correctly, custom SaaS development is unnecessary.
What this proves
Acceptance is expressed as observable state transitions and failure behavior, not “the dashboard looks right.”
Next step
Have an operating workflow spread across CRM, spreadsheets, inboxes and manual status updates?
Map one complete loop first. From that model we can decide what should stay configured, what should integrate, and what genuinely needs custom software.