I'm Stanley, a full-stack dev who ships solo. Recently launched PetEats (AI iOS app, on the App S...I'm Stanley, a full-stack dev who ships solo. Recently launched PetEats (AI iOS app, on the App S...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
I'm Stanley, a full-stack dev who ships solo. Recently launched PetEats (AI iOS app, on the App Store) and Net Pay (netpaytoday.com). I build AI chatbots, automation, Telegram bots and full-stack apps — Next.js, PHP, Python, OpenAI. Open for freelance work. DMs open
Building a 4-role real-time SaaS taught me one uncomfortable lesson: the hard part was never the code.
I've been building RestaurantOS — one platform connecting Owner, Kitchen, Waiter, and Cashier in a single live workflow (Table → Order → Kitchen → Serve → Billing → Reports).
The tech stack was the easy part. The real challenge: keeping 4 different roles in sync in real time without any of them stepping on each other's data — a waiter updating a table while the kitchen marks an item ready while the cashier is mid-billing.
That forced decisions most tutorials never cover:
⚡ How much state should live client-side vs. source-of-truth server-side
⚡ What "real-time" actually needs to mean per role (a kitchen screen needs sub-second updates, a report dashboard doesn't)
⚡ Designing failure states — what happens when the waiter's app loses connection mid-order
Currently redesigning the UI/UX layer too (motion, better visual hierarchy) while keeping this real-time core intact.
If you've built multi-role or real-time systems — curious what broke first for you. And if you're a founder who needs something like this built, my DMs are open.
I conceptualized and engineered this interactive manuscript recovery interface for Palimpsest Lab .
The build bridges the gap between archival scholarship and technical UI, pairing classical book typography with real-time multispectral simulation. Crafting a live wavelength scrubber that sweeps from 365 nm ultraviolet fluorescence to 940 nm infrared; letting visitors uncover an erased fifth-century Greek geometry treatise hidden beneath a medieval Latin prayer book; turned scientific telemetry into a hands-on story where every control has a clear, functional purpose.
A purchase order arrives by email. 38 seconds later it's registered, stock is checked, the team is notified and the client has a confirmation. Nobody typed anything.
We filmed the PO intake agent in TechFoundry IMS end to end for the first time. Watch it here https://youtu.be/zoVYPD8qpCs
Email comes in, the agent reads the PDF line by line and matches every line to the catalog, the PO gets registered with a status timeline, and an acknowledgment goes back to the client with the same lines on it.
The boring parts are the ones that made it usable. Only approved senders get in. Every email in and out is logged. And the agent never touches stock levels, it registers and notifies, people decide.
The part that took longest wasn't the reading. It was the matching. A supplier's PDF never uses your part numbers, so "resolve to catalog" is where most of the real work sits.
If you're still keying POs in by hand, I'm curious what your inbox looks like on a Monday.