1
Research the workflow
Start from observed behavior, real cases, volume, exceptions, spend and the people who own the process.
- Past cases and event data
- Current systems and workarounds
- Economic buyer and constraints
Product research & software development
Research first. Build what is worth building.
I study business workflows, validate the problem and economics, then design and build software, integrations and internal tools around what is actually worth automating.
B2B workflows · Integrations · Internal tools · Web products
Selected work
Products and integrations already in use
What I Do
Research, validate, integrate, build
Workflow Research
Map the current process, identify manual exceptions, existing spend, constraints and the real owner of the problem before proposing software.
Software & Integrations
Build web products, APIs, integrations and internal tools that fit the existing stack instead of replacing working systems without a reason.
Validation & Delivery
Start with a measurable pilot, compare it with the current stack or integrator, and scale only when the economics and repeatability hold.
Shipped Products & Integrations
Real software I have built and shipped
Multi-level Menu
Configurable multi-level visual navigation for online stores.
read caseCapabilities
From one costly workflow to a working software pilot
Research → Pilot → Build
Software around a measurable business workflow
I can research a workflow, map the current systems and alternatives, prototype the smallest useful intervention and build the integration or product if the numbers justify it.
Start
Workflow research
Build
Software & APIs
Delivery
Pilot → production
- Existing stack and integrator are evaluated before custom development
- Success criteria are defined with operational metrics, not feature count
- Integrations, internal tools, web apps and workflow automation
- Commercial terms are agreed per scope; secure online payment is available
Typical engagement
- 1. One workflow
Define the event, owner, volume, exceptions and current systems. - 2. Baseline
Measure time, cost, quality and existing alternatives. - 3. Pilot
Test the smallest intervention against the same cases. - 4. Build or stop
Scale only when value and repeatability are demonstrated.
Approach
Evidence before architecture. Existing systems before replacement. Measurable outcomes before scale.
2
Compare alternatives
A new product has to beat the current process, an in-stack improvement or a custom integration — not an imaginary blank slate.
- Current stack first
- Integrator / build-vs-buy comparison
- Full first-year TCO
3
Pilot and learn
Build the smallest test that can change the decision. If the economics or repeatability do not hold, stop instead of expanding scope.
- Before / after metrics
- Small integration surface
- Scale only after evidence
Typical Work
Where research and software usually meet
B2B workflows
Onboarding, account operations, approvals, exceptions and partner workflows.
Integrations & APIs
Connect existing portals, CRM/ERP systems, external services and internal data flows.
Internal tools
Operational interfaces, queues, admin tools and automation for repetitive work.
Product experiments
Small paid pilots that test demand, economics and repeatability before a full build.
Independent Product Research
I research repeatable business workflows before deciding what should be built.
Evidence
Measured workflow
Volume, manual exceptions, active time, current spend and the consequences of delay or error.
Alternatives
Existing stack first
A separate product only makes sense if it beats an in-stack improvement, integrator or manual process on the same scope.
Privacy
Operational, not confidential
For research conversations, anonymized counts, ranges and one representative case are usually enough. I do not need customer data or trade secrets.
If I contacted your team
It is usually about one specific workflow I observed in your market. The goal is to understand how it works in practice, what is already automated and whether any meaningful residual problem remains — not to ask for a generic sales meeting.
Reply or write directlyFrom Evidence to Software
A practical path from one workflow to a production decision
1
Scope one workflow
Define one event, one owner, one outcome and the current systems involved.
2
Measure the baseline
Use recent cases to measure volume, active minutes, errors, current spend and constraints.
3
Compare the alternatives
Compare doing nothing, improving the existing stack, custom integration and a separate product on the same scope.
4
Run a paid pilot
Test the smallest useful change with before/after metrics and a deliberately narrow integration surface.
5
Scale or stop
Turn the pilot into a reusable product only if the economics, deployment and support remain repeatable across customers.