> Usually, there's just no time to build internal admin apps when you're a solo founder or a small team.<p>At my current job, the "admin UI" is rolled into the same CRM we present to our customers, and often takes the form of e.g. additional panels on customer-facing pages that are only visible to admin users. In my opinion, this design was a mistake because it means we have to go to considerable lengths to make internal tools visually polished, despite them often being used by just one or two users who (a) work for us and therefore don't need any polish and (b) we can directly brief on how to perform a particular task.<p>At a previous job, the customer-facing CRM was as polished as you'd like but the admin tools were kept separate and, as a kind of informal company policy, were often deliberately designed to be _brutally_ simple. Black text on white background, no CSS, no Javascript except maybe for a JQuery plugin thrown onto a table to make it sortable. In some cases where we felt it was justified, we'd even just dump JSON onto a page and train the operator to CTRL+F to find the field they were interested in. Admin tools that were used by more users would receive slightly more effort, but the whole point was to keep these tools as simple and unpolished as they could possibly be while still being functional so the bulk of the devteam's time could be spent on customer-facing code. While this was an extreme contrast to my current job, I nevertheless find this approach a better use of the devteam's time. And as a bonus, it meant the friction to putting together a new admin app was much lower. If one or two of the admin users felt that they were being slowed down by an awkward workflow, it was entirely uncontroversial for the devs to throw together a quick microapp just for those users. If we'd had to do it by putting together an API with a React frontend and everything that goes along with that, we probably would have rejected most of those requests.