Best fit: teams with a painful manual workflow, internal tool idea, SaaS concept, integration utility or script collection that needs to become reliable software.
Working products are part of the portfolio
I have built and shipped tools including Steller PDF, Script Runner, HL7 QA tooling, synthetic message generators and other operational utilities. That product work informs how I approach client systems: make the workflow clear, make failures visible, and make the tool usable by someone other than the developer.
Automation should survive the person who wrote the script
A one-off script can save time, but production automation needs configuration, scheduling, logs, failure handling, documentation and a way for another person to operate it. Script Runner grew out of that exact gap.
SaaS and internal platforms should start with the workflow
The technology stack is secondary to the state transitions, users, roles, data, exceptions and audit trail. I map the process first, then build the smallest system that can reliably own it.
Custom does not mean unmaintainable
The goal is not clever code. It is clear interfaces, explicit configuration, documentation, predictable deployment, backups and safe handoff so the business owns what was built.
Common questions
Do you build complete products or only scripts?
Both. Work ranges from small automation utilities to desktop applications, internal web systems and SaaS-style platforms.
Can you integrate the custom tool with our existing systems?
Yes. APIs, files, databases, scheduled jobs and healthcare interoperability standards can be used where appropriate.
Do we own the deliverables?
Ownership, source-code handoff, deployment and support terms are defined in the project scope before development begins.