There are certain things in life that are meant to be unstructured and spontaneous. The moment you try to sandbox them they tend to devolve into noise which then calls for more structure or "rules", it's a slippery slope. If you're remote, you can always start a huddle and talk while you work, or if talking is not your thing, a good old DM can work. If you're worried about noise or things getting lost, you can always move the work related things into their own channel as they come up. Just 2 cents.
The food industry is due for a good old opensource disruption, where each restaurant can setup their private menu hub (like you would an instagram account), add their payment processing details, and start delivering their own orders. It's a win-win for the restaurant and their recurring customers.
Worked years ago at a restaurant that had its own website and app ordering...
Ubereats and the like still dominated the orders even with the 15% upcharge and even after notifying repeat customers that they can save money ordering direct
The convenience of having one centralized app with one account that can summon any food from any restaurant in a 10 mile area is just way too strong.
Plus the fact that you only have to give your credit card details to one large company that (hopefully) has some security professionals working for it, rather than dozens of smaller ones and hoping that none of them lose it/get compromised.
Consider supporting lower friction payment types like apple pay/google pay or any other which the customer is likely to be already using and don't need to enter their billing details to yet another random website. Maybe you already do.
The target audience for consolidated food delivery apps isn’t the person who wants to manage the fine details of ordering from 10-20 different local restaurants.
The majority of people using these apps just want to scroll some restaurants and order something quickly. Saving 10% by going through extra steps, installing extra apps, going to a company’s website, and doing custom orders isn’t what most of their repeat customers want to do.
I'm the one who don't bother ordering directly to get better value, but I started noticing less and less restaurants (that I order from) having this option anymore.
They probably saw too little people using it and stopped accepting, sadly.
Having dedicated delivery drivers stops making sense after a while
One benefit of these apps is companies which would never have had a driver now can be ordered, but the cost is all the businesses who did no longer do.
And it’s going to be a hard sell for a small business owner to pay for not employees that are in low demand by the consumer vs the zero fixed cost apps that manage that for you.
Stuff like this already exists (AFAIK not open source but cheap enough that restaurants would prefer to use it if they could). The problem is modifying user behaviour: people used to go directly to the restaurant to order food but are now very used to opening the food delivery app, browsing it, and ordering.
You could have the slickest ordering experience in the world and it won’t help you if no one sees it.s
These certainly exist. My local favourite Thai restaurant has its own ordering website and has its own staff deliver the order, with no markup over the in-restaurant menu prices.
The company that operates their ordering platform is mobihq.com (I have no affiliation with them)
There are middle man services for certain types of food in certain areas.
For example Slice is a popular one for pizza. I know a business owner who uses it.
They have an app and optionally an online menu on your custom domain to take online orders and physical hardware for taking orders in your store. Think POS system, register, terminal, printers, etc..
For a business owner that covers you for accepting online and offline orders, and you can deliver direct to your customers.
95% of his online delivery orders go through this system because DoorDash charges him (the business owner) 30% for each order so he raised his prices there to partially offset that. Slice on the other hand is 5% cheaper than his baseline price for online orders for customers so it's a no brainer most use that. With that said, way more people call in or come in person than using the app. Probably a 90% / 10% split.
It's crazy to think, but I think we're quickly reaching an inflection point where the generation of on demand multi-sided marketplaces that gained steam in the 2010s is ready to be disrupted itself.
Similar to how JustEats works. Or at least used to. The restaurants have their own driver, and create their own menu. Though I think the cut from JustEats is still quite high.
Yes, another case of old school web dev making a comeback. “HTML over the wire” is basically server-rendered templates (php, erb, ejs, jinja), sent asynchronously as structured data and interpreted by React to render the component tree.
What’s being done here isn’t entirely new. Turbo/Hotwire [1], Phoenix LiveView, even Facebook’s old Async XHP explored similar patterns. The twist is using JSX to define the component tree server-side and send it as JSON, so the view model logic and UI live in the same place. Feels new, but super familiar, even going back to CGI days.
Right? Right. I had similar thoughts (API that's the parent of the view? You mean a controller?), and quit very early into the post. Didn't realize it was Dan Abramov, or I might've at least skimmed the 70% and 99% marks, but there's no going back now.
Who is this written for? A junior dev? Or, are we minting senior devs with no historical knowledge?
I don't know you, but it sounds like you have principles you stand for and that's rare. If you have a talent for something that can do good in the world it's worth pursuing. I'd take a break and find a place that aligns with your values. Best of luck.
I appreciate the no-build-step approach. It’s refreshing to see a return to simplicity, even if it feels cyclical—similar libraries have come and gone, but that’s how the web evolves. As browsers continue to improve and embrace web standards, it makes sense to lean into tools that trend toward minimalism and simplicity. Great job!
If you are applying for a job in the front office of an NBA franchise, and I ask you "which team did Michael Jordan play for?", answering with "this is a useless trivia question, it is beneath me, I can easily google it, how does it matter?" will mean you are not going any further in the interview. You can then complain about it online all you want, but that's how it is.
Similarly, if I ask you "write a program in your language of choice that prints all even numbers from 1 to 100", you can either cry about it or take the 3 minutes and actually do it. If you can't, it's a pretty clear signal that you don't actually write code in your day job and aren't suited for this one.
Why would someone be under pressure when answering "basic fizzbuzz or reverse a string level questions"? Personally I like easy and quick warmup questions, they make me more calm
FizzBuzz trips people up for all kinds of reasons: fear of ‘gotcha’ questions, nerves, overthinking, or even feeling insulted by how basic it is. Sure, some fail because they can’t program—but passing doesn’t mean much either. It just means they’re good at FizzBuzz, not necessarily at solving real problems.
Sure, some qualified people fail simple problems. More likely the applicant failed because they didn't pay attention in school and made a career of copy-pasting stuff from stackoverflow(or AI these days).
This is a mix of laziness and convenience. Hiring often boils down to what’s easiest, not what’s best. Leetcode is a proxy: it quickly filters candidates and spares everyone from more effort. But if you hire based on Leetcode, you’ll get Leetcode engineers. If you hire based on track record, impact, and real-world projects, you’ll likely get someone who’s better—and actually fits the role.
If you want to do your part and can afford it, turn down any Leetcode based interviews and let them know why if they ask.
Yes, always keep basic statistics in mind. Every single proxy you apply that isn't correlated to what you really want will filter-out the outliers towards the median.
And remember what the median job candidate that applies to your place looks like. Do you want to remove the people that don't look like them? If yes, you are on the clear.
That’s fair, but most software jobs aren’t at top-tier companies. HR often stays out of the process due to technical barriers, leaving engineers to handle interviews. Leetcode becomes the easiest way to offload the hassle—ironically, a self-inflicted wound on fellow engineers.
