Service
Specialized software that improves the systems you already have
I design and build focused applications, integrations, and automation. Each project delivers one specific operational improvement. It closes a gap without replacing everything around it.
I’m not trying to build another ERP. Big platforms need big product teams, long timelines, and a support organization to match. My work is narrower on purpose: it makes the systems you already own more useful.
For municipal clients, that includes the platforms cities actually run: Tyler Munis ERP, CentralSquare CAD and RMS, Esri GIS, and Microsoft 365, including GCC tenants.
Where this fits
A few of the project types this covers:
- Internal business applications
- Department workflow systems
- Connections that let AI assistants read your existing systems
- Data synchronization between systems
- ERP extensions and add-ons
- GIS and operational-system integration
- Public-safety system integration
- Reporting and dashboard tools
- Import, export, and data-cleanup utilities
- Document generation and approval workflows
- Aging but still-important applications, modernized
- Secure internal and administrative portals
API development and integration
Nearly every system bought in the last decade, business or municipal, has an API, and most of them sit unused. This is bounded, well-scoped work a department head can approve without a capital project. It covers three different things, and buyers often don’t know they’re different:
- Building an API for a system that doesn’t expose one, or exposes one badly
- Consuming vendor APIs to move data between systems that don’t talk today
- Middleware and gateway services that sit in between and handle authentication, rate limits, caching, and logging
Where it usually starts
Most of these projects begin when a team decides one of these is worth improving:
- Staff retype the same information into two or three systems.
- A critical process lives in a spreadsheet only one person understands.
- Two systems hold related data but don’t talk to each other.
- The ERP is missing one small feature that turns out to matter a lot.
- Reporting takes a day of manual assembly every month.
- A vendor system has an API but no practical way to use it.
- An old in-house app is still load-bearing and nobody wants to touch it.
Something I built
TripSync started as a tool for one family trip and turned into a product: it takes a pile of confirmation emails and produces a day-by-day travel guide, with offline mode, tickets ready at the desk, and an SOS sheet for the bad moments. The demo trip is fictional. The application is real, and you can use it right now.
Websites are their own service
If the project is a website, that work has its own page now. A dated site gets a modern, secure, accessible rebuild that connects to the systems behind it, and it’s often the fastest way to start working with me.
How I work a build
- Start with the operational goal, not the technology.
- Map the current process and the systems involved.
- Find the smallest solution that actually solves it.
- Settle security, ownership, support, and lifecycle up front.
- Build in increments you can see and react to.
- Test with the people who’ll actually use it.
- Document it and hand it over responsibly.
A real example
I built a read-only API gateway over a Tyler Munis ERP using the vendor’s OAuth. Other systems could pull live financial data through it, with no direct database access and no second round of data entry. That’s the shape of most good integration work: bounded, secure, and useful the week it ships.