Colin Tucker
I've spent more than 20 years building software that has to work outside the demo.
My background spans enterprise communications, desktop systems, real-time voice and video, and mobile applications. I've supported enterprise systems in more than 30 countries and built Android products distributed across millions of devices.
Today I focus on Android engineering, AI products, and technical product work. I build and modernize apps with Kotlin, Jetpack Compose, clean architecture, testing, and CI/CD.
I also build AI products. For Data Story Strategy I built the Commercial Translation Diagnostic, an AI document-analysis tool that keeps a human reviewer in the loop, and Rolo, the CRM the company runs on, which AI assistants can work in directly with a person approving every change.
A lot of my work starts with an existing system. The product has grown. Requirements have changed. Releases have become harder. Performance has slipped. New engineers have trouble understanding the code. Or the team knows what it wants to build next but the current architecture is making that harder than it should be.
That's the work I enjoy most.
I've led Android development, owned features from design through release, mentored engineers, worked closely with Product, Design, and QA, and modernized legacy systems so teams could move faster without sacrificing reliability. On one team that meant raising test coverage from 20% to over 80%.
I'm also interested in the human side of technical products. I built and shipped Elsie Home, an Android launcher for older adults and people with low vision, with large touch targets, voice commands, medication reminders, and a magnifier.
At Data Story Strategy, I work with companies when the product itself becomes part of the commercial question. Sometimes that means advising. Sometimes it means reviewing the technology and finding the problem. Sometimes it means writing the code.
How I work
I look for the real constraint.
Before rebuilding something, I want to understand what is actually slowing the product or the team down.
I build for the people who come next.
Maintainable architecture, useful documentation, testing, and reliable release processes matter because somebody else eventually has to work with what I build.
I stay close to production.
Performance, device behavior, releases, monitoring, and actual users tell you things a development environment cannot.
I work with AI, and build it into products.
AI tools speed up my implementation, testing, analysis, and documentation. I also build AI into products where it helps the people using them. Either way, experienced engineering judgment stays in the loop.