How I think about building
Two years, ten hackathon wins, three internships, one published paper and one presented at a conference. Every one of them started with the same constraint: a deadline that didn't move.
Most of what I've shipped was built in 24 to 36 hours, against a clock, on a team that had to agree on an architecture before lunch. That's not a workaround for how I'd rather work, it's the fastest way I know to find out if an idea survives contact with reality.
The internships taught me the other half: EaseworkAI needed agents that could actually hold a conversation between a supplier and a buyer, not a demo of one. ConnectWise needed a pipeline that kept working after I left the room. Neither cares how clever the model is if the system falls over on a Tuesday.
How I Operate
Ship first, polish later
A working prototype tells you more in a day than a spec tells you in a week. Perfect is a second pass, not a prerequisite.
Systems over features
A button is a feature. A cron job that ingests, classifies, and surfaces the result before the standup is a system. I build the second kind.
Constraints are the brief
One GPU, 24 hours, no budget, real limits force real decisions. I design for the constraint that's actually there, not the one I wish I had.