Partner-facing platform systems at Tillo
Working across APIs, integrations, and platform reliability where partner trust depends on both product shape and backend decisions.
About
Software is changing fast. I am interested in what happens when code gets cheaper and judgement becomes the real constraint.
I build software in the places where AI, product complexity, platform reliability, and engineering quality all start affecting one another.
My background is full-stack, but the through-line is broader than a stack. I am drawn to the places where architecture, product thinking, engineering quality, and team systems all affect one another.
Current focus
- Reliable partner-facing APIs and integrations at Tillo
- Agent-assisted engineering workshops and workflow tests
- Specification-first habits for clearer delivery
How I think
AI has made the future of software feel wider, faster, and noisier. What interests me is not the hype cycle. It is the shape of the real work underneath: what changes when implementation gets cheaper, how teams keep quality high, and what sort of judgement becomes more valuable rather than less.
I like the problems that sit in the joins. Sometimes that is architecture. Sometimes it is product definition, API shape, operational reliability, or the boundary between what a tool can generate and what a team still needs to think through carefully.
Maintainability is the through-line. In a world of faster generation, the differentiator is not who can produce the most code. It is who can keep systems understandable, trustworthy, and worth evolving.
What I am drawn to
Automation and product systems
How tooling, automation, and humans work together once more of software delivery is delegated, reviewed, and verified.
Systems with real constraints
Architecture, APIs, integrations, reliability, and the trade-offs that decide whether complexity stays manageable.
Product and engineering judgement
Choosing what deserves sophistication, what should remain simple, and how technical decisions support the product instead of fighting it.
Teams that want clarity
I enjoy environments where communication, quality, and thoughtful collaboration are treated as engineering work, not overhead.
Working principles
- Start from the system, not the isolated feature.
- Prefer clarity that compounds over velocity theatre.
- Treat product, design, and engineering as one conversation.
- Assume maintainability is part of the user experience.
Proof in practice
20% API response-time improvement
Used Datadog APM and targeted refactors to improve production performance across key endpoints.
PHP Guild across 25 developers
Created a cross-team forum for engineering quality, shared practices, and standards such as static analysis adoption.
Agent-assisted engineering workshops
Running practical sessions on where automation helps, where it fails, and how judgement still shapes shipping software.
Background
My path has moved through mobile, frontend, backend, infrastructure, and delivery leadership. Today I work at Tillo on partner-facing platform systems. Previously I worked across Tutorful and Sonin, building products that needed both technical depth and practical trade-off thinking. Earlier still, I grew from intern to full-stack developer by learning how real systems behave once they are used every day.
That breadth matters to me because it shapes how I see software: not as isolated tickets, but as connected systems with product, operational, and human consequences.