Todd Watts / Shell Command, LLC

Fractional CTO for mid-sized service businesses.

Through Shell Command, LLC, I help service businesses in finance, quant and tax set technical direction, shape system architecture and build the software.

Discuss your business Explore the role

[ from decision to delivery ]

     +-------------------+
     |     DIRECTION     |
     |   choose a path   |
     +---------+---------+
               |
               v
     +-------------------+
     |   ARCHITECTURE    |
     | connect the parts |
     +---------+---------+
               |
               v
     +-------------------+
     |       BUILD       |
     |   make it work    |
     +-------------------+

Technical leadership with an engineer at the keyboard.

01 / Fit

A decision needs an owner.

A fractional CTO brings technical leadership to a business without a full-time executive appointment. My work connects that leadership to system architecture and hands-on software development.

That can be useful when the business knows something needs to change, but the technical direction is still unsettled:

Should we build software, buy a product or connect what we already have?
Which parts of a system need to change, and which are worth keeping?
What is the smallest useful first step, and what will it mean for the rest of the system?

These are starting points for a conversation. The right scope depends on your business, your existing team and the decision in front of you.

When does a service business need a fractional CTO?

02 / Responsibility

Direction, architecture, implementation.

Technical direction

What should we do next?

Connect the business problem to a technical decision. Compare the options, make the constraints explicit and decide what is worth building.

System architecture

How should it fit together?

Work through how the parts connect, where data and responsibilities live, and what needs to happen when a dependency fails.

Hands-on development

How do we make it work?

Build the software, interfaces and integrations. Bring implementation detail back into the architectural decisions as the work takes shape.

Work through a fictional build, buy or integrate decision, or see how to plan a roadmap before a rewrite.

03 / Evidence

Inspect how I think.

Public code, original demonstrations and colleagues’ recommendations give you different ways to evaluate my work.

Public source code

MAINFRAME

A Pi package for shell policy, checkpoints and inspectable status. Read the implementation and its documented boundaries.

Explore MAINFRAME

Original engineering demo

The lending lab

Try duplicate requests and failed notifications in a fictional telescope lending desk. All data and scenarios are synthetic.

Try the experiment

Public professional context

Colleagues’ perspectives

Read attributable recommendations about technical skill, communication and working together, with links to LinkedIn.

Read the recommendations

The code and demonstrations are independent work. They show engineering choices you can inspect, not client systems or claims about client results.

04 / First conversation

What needs to work?

Tell me about the business problem, who handles technology today and the decision you need to make next. A high-level description is enough to start.

We can discuss the technical responsibilities, the scope of the work and whether fractional leadership or a focused build makes sense.

Discuss fractional CTO support

Hiring a software engineer for your team? Read my résumé or get in touch about a role.