Arturo Solo

Arturo Solo LLC · Workflow and AI systems

When your workflow
no longer fits
the work.

Let's reconstruct how the work actually moves, find the real constraint, and decide whether to simplify, buy, automate, build—or use AI only when it earns its place—so you leave with a decision path, and when you build, a reusable workflow your team can run.

Scattered work inputs consolidating into a clear ordered workflow path

Built work. Real operating context.

The proof is practical: reconstruct how the work moves, find the real constraint, and decide the path—described at the level the evidence supports, not inflated into outcome claims. When we build, the aim is a system the team can run.

Public products

Software shipped outside client work

Internal workflows

Operational tools and processes

Client contexts

Small organizations; leaders close to the work

AI work

In development, clearly labeled

Client contexts

DMDL

Client workflow · beta

DMDL

What looked true
External service providers had to scan a printed QR code into a Google Form on arrival and again on departure. The proposed fix was a DMDL-hosted form that auto-marked the visit complete via geolocation when the provider left the site—so they would not complete the form twice.
What discovery found
The field team needed a real check-in system: capture visits on phones, sync to the office, and record provider sessions. Shipping a PWA plus web portal features looked like the obvious next step.
Path that followed
A PWA and portal supported about forty providers and office staff, but iOS browsers do not support background location. Users hit bugs where the PWA was expected to behave like a native app.
Status
The PWA path was retired. Mobile is rebuilt as native iPhone and Android apps with Expo/React Native. Beta: admin and staff testing the website portal and native apps; external workforce testing the native phone app.
What this means for you
On mobile, users often trust a native app more than a PWA—regardless of how well the PWA performs. Test the platform assumption before you lock the architecture.
Joy for Books

Client system · in development

Joy for Books

What looked true
A custom CRM-style app needed a school event as its center—the hub where inventory, distributors, and reviews all connected.
What discovery found
Book inventory was the real center. Without books, the other business units would not exist.
Path that followed
A first web application framework was built on the event-centered model, far enough for the client to test. Further discovery showed inventory should be the focus; AI helped revise the requirements document, and the app is being rebuilt around that center.
Status
Active development. Not framed as a finished portfolio outcome.
What this means for you
Start from how the work actually hangs together—not the first object that looks like the center of the system.
Bring a recent example of where the work breaks

A concrete stuck workflow—not a feature list or predetermined tool.

Start with the decision. Build only when it earns its way in.

Two distinct engagements: Workflow Assessment establishes what should change and why. Custom AI Build implements a separately approved scope when the evidence supports it.

Workflow Assessment

A seven-business-day decision on what to change next.

I reconstruct one consequential workflow, identify the real constraint, and compare simpler process, existing software, automation, AI, and custom development.

What you receive
A decision-ready Implementation Brief: the current workflow, the recommended path, the evidence behind it, and the smallest valuable next step—followed by a findings and decision review.
Decision paths
Simplify · Buy · Automate · Build · Investigate · Defer
Best fit
Small organizations where leaders wear many hats, decision-makers (or strong recommenders) are close to the work, and one consequential process is costing real time—with a recent example we can examine.

$1,500 fixed fee · Seven business days

The seven-business-day clock starts after payment and kickoff, with the decision owner, workflow lead, and agreed materials in place.

Workflow Assessment does not include a prototype or production implementation. Those are authorized and priced separately only when justified. The assessment fee is not automatically a deposit on a future build.

See if the assessment fits

Custom AI Build

Separately scoped implementation for a validated workflow—built to hand off.

For workflows with a supported need and a clear reason custom software or AI is the right path. That evidence may come from a Workflow Assessment or equivalent discovery already completed by your team. The goal is a reusable system your team operates, not a one-off task utility.

How it works
We agree on the smallest useful boundary, acceptance criteria, ownership, and any feasibility tests before committing to implementation.
Ownership
Designed so your team can run it. Handoff, operating responsibility, and acceptance are explicit in the approved scope.
Feasibility first
When success depends on uncertain platform, API, device, or data behavior, we test that assumption under representative conditions before committing to the architecture.
Delivery
Build, representative testing, client acceptance, release, and post-launch responsibilities are defined in the approved scope.
Discuss a scoped build

Map the work. Choose the path. Build only what is justified.

01

Reconstruct the workflow

Walk one representative case from trigger to completed state. Identify the people, records, systems, handoffs, exceptions, workarounds, and the source that wins when records disagree.

02

Find the real constraint

Separate the requested feature from the operational problem. Compare simpler process, existing software, automation, AI, and custom software against the same requirements and evidence.

03

Act on the decision

Simplify, buy, automate, investigate, or defer—or separately scope a build with acceptance criteria, feasibility gates, a measurable boundary, and an explicit handoff so your team can operate what ships.

Arthur Turnbull

Why Arturo

Builder's judgment. Operator's discipline.

I can map the operation, test the hard assumptions, and build the software myself. That does not mean custom software is always the answer. You get one accountable partner who can recommend the lower-complexity path when it fits, carry a justified build through implementation when it does not, and leave you more capable of running the work—not more dependent on me.

  • ·Hands-on workflow assessment and implementation
  • ·Evidence and tradeoffs in plain language
  • ·No predetermined AI or custom-build pitch
  • ·Leave capability, not dependency