My own take on how I'd implement the multi-tenant architecture, with some comparisons and why I disagreed with RestaurantOrder's way.
Published on Feb 6, 2026
Updated on Feb 6, 2026
To recap, I am currently doing a UI/UX designer role in my capstone project for Bachelor’s. But I do disagree with a lot of how they design the database, the architecture and such to qualify for a multi-tenant architecture.
You can read my rant here.
There are two projects concerned here, which should provide the same value, but different philosophies and how operations are typically done. One of them is called RestaurantOrder by the team, and one of them is FoodBasket by me. But both should provide a restaurant-domain POS system and a food ordering system with multi-tenancy.
I understand that keeping the scope small enough is a valid requirement, but please also keep in mind that this project has to consist of 6 members expected to work on the project at least in a part-time to full-time fashion, across 8-10 months. All of them are seniors (Year 4) with almost no courses left to allow them to focus on this project, and to finally present and defend the project to the committee at the end of the run.
So all in all, even if you don’t like it, there are a lot to consider while doing it. Sometimes simplicity would get you drilled in front of the committee, and sometimes too much complexity would get you too out of scope to finish it in time. Or also drilled in front of the committee.
My argument is that the tech stack has to be maintainable, approachable and matured enough to be actually safe across almost a year, until the presentation. I don’t think we should try on an extremely new framework, just because some developers like it, or too many libraries outside of what the standard framework gives, as I also believe each new library is a moving part you need to consider.
If it was up to me, I’d have gone with something mature, battle-tested enough and prioritize both UX and DX at the same time, something like Express and React with TypeScript. From now, I’d call them the “Team” to be concise.
Until I found out that these are relatively new frameworks, they still contain a lot of library-level wrinkles that haven’t been ironed out yet. I still wouldn’t consider DX to be big enough of a priority to choose such new frameworks.
I’m not against NestJS or Tanstack per say, what I’m against is oRPC. In 2 months, there have been constant issues about api contracts not syncing up, having to be resolved by force rebases, force commits and forcing every branch to catch up, with 2 tickets having to be resolved by oRPC developers because they were bugs inside the library. I’ll outline what the team has done in 3 months regarding the project later for you to judge on your own whether that was a good call to use such a tech stack.
I did it this way to allow mostly just for maintainability. As long as they all share the same authentication/authorization model, I think having a few frontends be server-rendered for performance as well as Google indexing might be a good side benefit.
Every developer has their own set of libraries they like to use. But the philosophy of the one using them might differ.
This is fine to some extent, until you get to a few problems:
If I was the one calling the shot for the team, I’d let them go with Shadcn, but would draw the line at BetterAuth. Someone once told me, you don’t have many innovation tokens in a project, and usually you should spend those tokens on features or designs that make the project different and unique, rather than on non-mainstream libraries. And for the team, it seems like to me that they spent too many tokens on libraries and frameworks. In the end, the product just feels like a constrained spreadsheet experience in some workflows.
I strongly believe that software development doesn’t stop at just coding, there are still a lot of processes to be done. And with the rise of LLMs recently assisting, I see no reason why you can’t use LLMs to proof-read and assist in writing specifications and documentation. I don’t really trust LLMs in writing code for me unless it’s a very small and contained file, but for proof-reading documentation, and rewriting them or catching small missteps feels like something that a large language model would excel at.
When something goes wrong, we just know what goes wrong, but the process leading up to why it goes wrong falls back to blaming, “Oh she didn’t read the file but we actually had it”, “it was detailed enough”, “it was clearly written”.
Again, if I was the one calling the shot for the team, since a sprint is 1 week, I’d have them write and review each other’s documentation and specification for the first 2 days, and then spend the next 4 days implementing, or 1 week of docs and 1 week of implementation. But to quote my professor, “You don’t need that, that’s all fluff and unnecessary”.
This clash stems from the fact that there are no actual user research, market research, market-fit research done at all, but just considering already available options, mainly TastyIgniter and GloriaFood. We of course don’t have the resource to sit down with managers and ask, but I think going to restaurants, asking one or two questions as probing, or bouncing ideas off other friends outside the group would also be a budget way to conduct research.
This got fueled to blow up harder because there are also no solid software requirements specifications, or SRS that documents such as “Given …, The system shall …” format. When inquired about it, the team actually says that the features list IS the required SRS, and the professor agreed that the features list is enough.
In short, the professor and the team believe that the software has to be “dumb and rigid” to prevent flaws, but that risks having a very low ceiling and being frustrating for power-users. I believe that the software has to work along side the user, with a relatively low floor but a very high ceiling. I want the manager’s 4th hour into the shift, getting interrupted by customers and employees to still feel like they don’t have to fight the system.
Somehow, this is Point 5, but this was the first we ever clashed on. Due to the budgeting nature of Vietnameses, as well as extreme favoritism for “free” tools, even if it’s piracy, they never looked into solutions that might cost a bit. Being students and all, I do understand that, but when you calculate the costs, it costs no more than a cup of milk tea per month for each member, then it begs the question, is it worth going with lower quality free tools still, or is it worth buying a cup of milk tea every month for a higher-quality paid tool?
For example, if I were to inquire for a Figma license to do my work in, they would 100% deny. Extremely thankful to the Figma team to allow Education licenses, or I might not be able to use all the tools possible to do my work. For a professional team, you would expect 5 developer licenses and 1 designer license, right? But this is very understandable as a free license still provides enough for this, even in the case of no Education licenses. The Edu license did help a lot with dev hand-off though.
I know that even as students, we don’t have the luxury of going with industry-grade tools like AWS or GCP or Azure, but budget options are out there, if you spent a little bit of time to look.
To total that out, you pay around $13/mo (including taxes) for the paid services, divided by 6 members, would be roughly no more than $2.5/mo. A single milk tea cup in an entire month. Is it worth it to distribute so many services across so many providers, just to save on that cup?
There are massive clashes here from the start, but I let the developers design this part on their own, trusting their expertise. And the two most prominent developers wanted to design this part anyway.
This is a rather fair point, I’d say if anyone of them didn’t have much experience with infrastructure or deployments. This makes it much easier to do it, but there exists some user flow-related pain points, such as there’s no good way to switch between restaurants without logging out and relogging in. Or being forced to belong into a team (BetterAuth term for branch here) to do anything.
My idea is absolutely a lot more complicated, but I think it also provides a huge talking point if it was asked in front of the committee. It was inspired greatly by other platforms like AWS, and gives a heavy exposure to infrastructure and deployment experience. And given 5 developers in 8 months? I think this can absolutely be done.
There are probably more to speak on, but I want to end this blog before it gets too long. Finally we will touch on interface design philosophy. Remember that the professor is saying we have to aim towards managers and workers running around on greasy tiny tablets.
While the ‘Table-First’ approach follows traditional legacy POS patterns, I believe it underestimates the digital literacy of modern restaurant staff. At the end of the day, it does just feel like a laggier, a more restricted version of a spreadsheet. If they do target mom-and-pop brands, I wonder myself, would they rather fall back to just a notebook and a pen? If they target a larger chain with many branches, would they be able to do their work efficiently having to scan tables and run filters, searchs and paginations on every workflow?
Even then, tables are notoriously dense in data, and would require horizontal scrolling on smaller devices, given that the professor hated horizontal scrolling and demanded that scrolling can only be in one direction, I don’t see how that’s doable with tables. With greasy tablets, I do believe that the rate of mistaps would be exponentially higher.
I wanted this product to give off a value, a more targeted set of users that may benefit highly. I want to avoid the saying, “good for everyone, great for no one”, and provide a truly different experience to other tools, targeted at power users, those who are on the “restaurant floor battlefield”.
It sounds rather complicated, but those are just terms. At the end of the day, on the UI, it just has a drill bar like a menu bar, and clicking an option is that axis rotation. I made it this way to allow the workspace section to see live data, and provide context and actionable data to the user, with unnecessary options or editing tools tucked away until requested. I think it’s the best option because due to its progressive disclosure nature, it’s instantly adaptive to all user devices. Some more benefits that this accidentally gave me that I didn’t think of until pointed out by friends or AIs:
It is, admittedly, a bit more difficult to learn than a table. But I think anyone that has ever used a phone before can learn this. From my observations in actual restaurants, managers and employees are relatively young people, comfortably working with technology, so my rationale would be “Why limit them to something slow?”
I do understand that the project is supposed to be a white-label system, and allows tenants to register their own color theming for the system. But that’s not what I’m talking about, I’m referring to the platform itself. What will the platform’s branding be?
I understand this as developers just want to do it with Don’t Repeat Yourself, and
make it much more flexible and easier to change, if there is a change. But there’s
a problem with Figma, they don’t allow variations on a color, such as Tailwind’s
OKLCH scaling, or custom opacity on a color. When you set primary as a color on
Figma, there’s no way to make it well enough with semantic tokens. If only, Figma
added a feature to allow decoupling of opacity and scaling away from the colors.
It’s also extremely restrictive in a design point of view, because you can’t use
any weighted variants of a color, because it gives off the same problem. Changing
one -500 color, for example, requires you to change every single instance of
it having a different opacity. It’s easy for developers to change, not easy for
the designer to do so. If they have DX for developer’s experience, what about,…
DX, designer’s experience?
This point is not too much of a clash per say, just the way we think being different, and I argue that both are valid. Except the part of not naming your project properly. Like I understand developers are terrible at naming, but at least put some effort in?
Wow, there were a lot to document out for this project alone. I hope you had a nice read, and understand why I launched an open-source version of the project, but with my visions and styles instead. There are a lot more points I want to speak on, such as authorization and authentication, database design, team workflows, git usage, but I think those are more nuanced, and a bit too small to make a point, but still do contribute to the clashes.
I may be a little selfish, but I wanted my last project in school to be something I can be proud of, and put onto the resume, and I can enthusiastically explain decisions, trade-offs made during the process to future recruiters or even peers. I feel like doing the professor’s way is safe, and just makes it look like a more team-effort to-do app than an actual product worth investing in.
It sucks that I believe that the developers are truly good, and are capable of producing more than a traditional CRUD app. But if your bottleneck is the professor that stunted design works for 3 weeks because he asked for proof of the interface design benefits, and dismissed it, then there’s really no hope for this. There’s a reason why the OSS version existed with my vision, to save my sanity.
I noticed a lot of clean architecture specifications don't have any demonstration on what it would look like in practice. Taking the chance of learning it in a course of Software Architecture, I think I would like to write up a demo just like so!
Registering and Logging in with user accounts, along with session tokens for authorization stored in HTTP cookies, made possible with CORS (CORS is a pain).
My first steps into my biggest project yet, a full-stack application for a comic-sharing website like Wattpad, Webtoon, etc. My first time ever setting up the server on a self-hosted VPS.