When the integration is the product
Half of restaurant tech is talking to systems you don't control. Notes on retries, idempotency and failing loudly enough.
Read itJOHNNY BRYANT
For the last eight years I've worked on guest-facing web applications, backend services and the third-party integrations that hold them together — mostly in restaurant technology, and more recently on AI-enabled products. Day to day that's |
I'm a senior software developer working remotely from Florida. Most of my career has been spent in restaurant technology — digital ordering, guest-facing apps and the operational systems behind the counter — where the interesting problems are rarely the pretty ones: menu and order data that has to stay correct, integrations with systems you don't control, and workflows that can't fall over at dinner rush. These days I do similar work on AI-enabled products at NerovixaAI.
Eight years of it has been full-stack product work: the customer-facing part, the services behind it, and the integrations that make the two agree with each other.
Guest-facing apps and internal tools, built from the interface down to the services behind it.
Ask me about itREST-oriented services and the operational workflows that sit on top of them.
Ask me about itGetting your systems talking to the ones you don't control — POS, payments, external ordering.
Ask me about itAI-assisted processing, document generation and API-driven workflows built into real products.
Ask me about itMenu, order and customer-data flows across branded ordering channels and operator tools.
Ask me about itProduction troubleshooting and the unglamorous work of keeping high-traffic workflows steady.
Ask me about itAPI-driven workflows for job discovery, application assistance and document generation, with AI-assisted processing behind them.
Web applications and APIs for restaurants taking orders on their own channels, keeping the customer relationship theirs.
TypeScript and C# work connecting ordering workflows to external restaurant systems, and keeping menu and order data in step.
API-connected workflows tying guest self-service ordering, payment and the operator-facing side together.
Integrations between application services and external restaurant technology, including POS-oriented ordering flows.
Internal services supporting digital workflows and software automation — reusable components and clean integration patterns.
You tell me what the system needs to do. I ask a lot of questions — probably more than you expect.
A short written plan: what I'll build, the trade-offs I can see, and roughly how long it takes.
You see it as it comes together, so if something isn't right we change it early.
Shipped, documented, and handed over properly. I'm still around when something breaks at 5pm on a Friday.
AI-enabled web applications, APIs and internal services. I build the full-stack side in JavaScript and Python, and design API-driven workflows for job discovery, application assistance and document generation.
Web apps and APIs for restaurants' own online ordering. TypeScript and C# across ordering workflows, restaurant operations and integrations with external systems — plus the performance work that keeps high-traffic ordering reliable.
Full-stack services for a hospitality commerce platform spanning ordering, payment and restaurant operations, with API-connected workflows joining mobile guest experiences to operator-facing systems.
Customer-facing ordering apps, API integrations and cloud-based services, including integrations with POS-oriented and third-party restaurant technology.
Software engineering, algorithms, data structures, databases and full-stack development. ACM, Programming Club and a fair number of hackathons.
The fastest-moving part of my job: LLM-assisted processing, document generation and API-driven automation built into products people actually use.
Structured debugging, reusable components and clean integration patterns. Most of the value I've added has come from making existing systems steadier rather than building new ones.
Half of restaurant tech is talking to systems you don't control. Notes on retries, idempotency and failing loudly enough.
Read itWhere prompt work belongs, what to do when the model is slow, and why the boring queue in front of it matters most.
Read itWhat high-traffic ordering taught me about latency budgets, timeouts and the difference between fast and dependable.
Read itEmail is usually quickest, but the form works too. Whether it's a role, a contract or a system that's misbehaving, a rough outline is plenty to start with — I'll reply within a day or two, and I'll say honestly if it isn't something I should be taking on.