Fit
This work fits teams with an active product initiative, meaningful workflow stakes and willingness to examine the product model.
Expertise
B2B SaaS and Workflow Software
Tcules designs B2B products around the operating reality beneath the interface: objects, roles, rules, states, exceptions and decisions.
- B2B SaaS
- Workflow software
- Product modelling
Does this condition resemble yours?
This expertise is especially relevant after product-market fit, when one successful workflow has become many variants across teams, plans, markets and integrations.
- The same object means different things to different roles.
- Status labels describe screens but do not explain what can happen next.
- Permissions have grown as one-off exceptions.
- Teams export data because the product does not support a real decision.
- Automation works on the happy path but exceptions return to messages and spreadsheets.
- Design and code describe different versions of the product.
- An AI feature is being added without a clear authority or evaluation model.
These are not separate interface defects. They are signals that the product model and operating model need to be read together.
The happy path is the easy part. The value of workflow software is in who may act on each state, what other roles can see, what happens when the rule does not fit, and whether the record can be trusted after every handoff.
A workflow product can be described in five questions
- 01
What are the durable objects?
A request, account, asset, campaign, incident, project or meeting persists while its presentation changes.
- 02
Who can see and change them?
Roles are not just access levels. They carry responsibility, authority and handoff.
- 03
Which rules govern movement?
Eligibility, approval, assignment, validation and automation decide how an object changes state.
- 04
Which exceptions matter?
The product becomes dependable when it explains and recovers the non-happy path.
- 05
Which decisions must the product support?
Dashboards, alerts and AI recommendations only matter if someone can act with sufficient evidence.
Representative operating model
A composite product scenario showing how objects, roles, states, decisions, evidence and next states relate. This is not client history.
| Object | Role | Current state | Permitted decision | Evidence required | Next state |
|---|---|---|---|---|---|
Service request | Coordinator | Awaiting assignment | Assign or escalate | skill, capacity, SLA class | Assigned / Escalated |
Exception | Reviewer | Evidence incomplete | Request evidence or reject | source, rule, history | In review / Closed |
Account | Administrator | Access change pending | Approve, modify or decline | affected users and work | Active / Restricted |
How Tcules shapes the product
Tcules can investigate the real workflow, model its objects and state transitions, define role and permission behaviour, design the interface and shared system, prototype consequential paths, and carry the product model into frontend, backend, integration and QA work within the agreed scope.
The client remains the authority for business policy, regulatory interpretation, source data and production permissions. The boundary is made explicit because a convincing interface cannot compensate for an unowned rule.
How capabilities combine
Product conditions are matched to likely responsibilities. The combination follows the product decision and does not require every engagement to consume every capability.
| Product condition | Likely responsibility |
|---|---|
Uncertain workflow or 0-to-1 model | UX research, product modelling, prototyping |
Post-PMF role and state growth | Information architecture, workflow design, interaction design |
Interface and code divergence | Design system, design engineering, implementation QA |
Modernisation under continuity constraints | Product modernisation, staged software delivery |
AI entering a consequential workflow | AI Product UX, evaluation and AI Product Engineering |
The combination follows the product decision. Tcules does not require every engagement to consume every capability.
Evidence across product conditions
- 01
Doodle
Doodle case studyShows an enterprise scheduling model built around participants, availability and meeting state.
- 02
Scissors
Scissors case studyShows research and object-oriented modelling in staffing software.
- 03
Ryzeo
Ryzeo case studyShows a marketing automation product restructured around clearer workflows.
- 04
Dealpath
Dealpath case studyShows a pipeline path corrected at the product-rule level while surrounding actions remained substantially unchanged.
- 05
BuildTwin
BuildTwin case studyShows an AI result becoming a review record with evidence, correction and escalation across three roles.
- 06
Benchmark Gensuite
Benchmark Gensuite case studyShows a high-reuse enterprise selector moving from visual upgrade to information-architecture repair through coded review.
AI should attach to a decision
In workflow software, AI may retrieve evidence, summarise state, recommend a next action or execute a bounded step. Each role requires a different control. A recommendation needs basis and alternatives. An action needs permission, preview, state and recovery.
The interface should never make probabilistic work look like a deterministic status merely because both appear in the same table.
Fit and non-fit
Non-fit
It does not fit rate-led production outsourcing or a request to decorate screens while the underlying decision remains out of scope.
Bring the workflow, product map or roadmap decision
Use the product model, operating rules and delivery constraints to decide what should happen next.