A focused first release
Define users, roles, screens, and the main workflow. Turn those into a usable application with the rules and validation your business needs.
Web application development
Software for the way your business actually works.
Customer portals, internal tools, SaaS products, and connected business systems.
Based in Columbus, Ohio. Available for remote projects.
01
Where I can help
When a process depends on copying information between systems or remembering who has the latest spreadsheet, the cost shows up in daily work. I build applications that make the next action, the current state, and the person responsible easier to see.
The first version should complete a useful workflow. That could be a customer moving from quote to booking, an operations team managing dispatch, or a subscriber using a new product. I work through the data, permissions, and integrations needed to make that workflow dependable.
02
What we can build together
Connected data and systems
Connect existing APIs, payments, reporting, and business tools. Plan data migration, account permissions, and error handling around the systems you already depend on.
A maintainable application
Deliver reviewed code, tests for important behavior, a deployment process, and handoff notes. Agree on monitoring, backups, and support responsibilities before production use.
03
All work →Relevant work
PH Cleaning Co
My cleaning business combines a public quote experience with separate scheduling and dispatch software. The website and operating workflow belong to the same system.
View project ↗
ChildScribe
My beta product combines a guided voice interview, private journals, subscriptions, and a path to printed memory books, with web and mobile interfaces.
View project ↗04
How we'd work together
- 01
Map a real workflow
Walk through the current process, examples of the data, and the difficult cases. Identify the smallest release that solves a meaningful problem and agree on acceptance criteria.
- 02
Build in reviewable stages
Review working software as it develops. Test permissions, integrations, and failure cases alongside the ordinary path, with explicit decisions about scope changes.
- 03
Launch with a plan for ownership
Verify the deployment and agree on who handles incidents, infrastructure, and future changes. Ongoing development can continue as a separately scoped engagement.
The first conversation defines the fit. Scope, price, and timing are agreed before work begins.
Questions
Can you take over an existing application?
Yes. I start by reviewing the code, deployment process, dependencies, and current problems. That gives us a basis for deciding between targeted repairs, a larger refactor, or replacing a particular part.
Can you connect the tools we already use?
Often. I first check the available APIs, access permissions, and limits. The scope should name the actual systems and operations involved so the integration can be tested against them.
How do you estimate a project?
We define the initial workflow, integrations, risks, and acceptance criteria, then agree on an estimate and engagement structure. Larger or uncertain projects may need a paid discovery phase first.
Start a conversation
Tell me what you need to make work.
These details give me enough context to suggest a useful first step.
- What the application should let someone accomplish
- Who will use it and what tools or data it needs to connect
- What exists today, plus any launch deadline or budget range
jeff@hooton.codes