Build dirty and clean up afterwards?

Question

Hi crowd,throw-away account for obvious reason.I work at a SaaS company, that has a product consisting of a web backend and an app frontend. I work there for 2 years, and have 13 years of experience in the industry, working as a software developer. I have worked on products and projects alike.The company I'm working for is now a decade old, and started with a dozen people. It was VC funded, and had a pretty strong incentive to get to the market real quick. This now shows, as the code for the backend and frontend is subpar, with questionable architectural decisions in the past. However, architecturally, the app frontend is in better condition than the backend.The market (=our customers) more and more demand not only a web backend, but also a web frontend. While a team currently reworks the backend, another team is formed which should build up a web frontend.There are two ideas: One is to build the web frontend as quick as possible, so that we can deliver a much wanted web frontend as fast as possible. We would copy the architectural, not-optimal idea and UX from the current app and put that into the web frontend. The idea is than, for the 12 - 18 months after release, to rework the web frontend architecturally. This would allow almost no room for feature development. This is also the road the web backend is currently taking, where I wasn't involved in the decision making process.The other idea is to put the invest up-front, re-thinking existing ideas, and build the web frontend without repeating mistakes from the past. This would allow to focus on features after everything is done. It will however mean that the release of the web frontend will happen later.While I cannot go into much more detail without giving away my identity, I'd rather prefer the latter.My argument against the first way is that, we as a company, may not be able to withstand the pressure to deliver features, as our comptetitors now already can do things we cannot do. Also, with the rise of AI-assistance, we will sooner or later need to integrate certain features into our frontend. In the past, everytime a "we will do it better afterwards" was announced, the phase of "doing it better" simply didn't happen. I'm burned on this one.The argument against the second way is, that we, as a dev team, proved in past features that we cannot focus on the scope and might blow up the whole thing, if we want to get the architecture and UX right in the first step. It was basically questioned that we have the competence to build what was asked.What do you folks think?

austin-cheney · Accepted Answer

It sounds like you don't know what you are doing. Don't be shocked, not knowing what you are doing and praying that a tech stack will do it for you is the norm... by far.
It can be done correctly and faster and cost less than alternative approaches. Here is how you do that:
1. Start with the end in mind. Know what you want from a product perspective and write that down. Most places are not capable of getting this correct. The more precisely you know what you want the less it will cost to build.
2. Know the platform. Most people have absolutely no idea how the front end works and are completely reliant upon some tool chain. A tool will allow setting up an application somewhat quickly in the absence of a plan, but again the costs will spiral up as you build it. This is why software is hard to estimate. If you don't know what you are doing then hire a temporary consultant to drive this bus. A framework or build tool is the most incorrect answer.
3. Automation. Supposedly software is written by software people and yet rarely are things well automated. You need centralized user-facing product documentation, test automation, code validation, accessibility, and such written in parallel to the actual product. If you know what you are doing this costs far less than you think. If you bolt it on later it will be extremely expensive and horribly incomplete.
4. Always remain focused on the product, the end state for the user. Most shops get this wrong too and instead think about their tools, code vanity, popular trends for hiring, and other irrelevant distractions. Focus.
I hope this goes well for you.

Archelaos · Answer

One aspect in favour of the first solution (making the transition as fast as possible, without re-architecture first) is its greater flexibility. You probably can break down the re-architecture requirement into several parts afterwards. Ideally, you can treat each of these parts as an individual feature having its own priority and put them into the same basket as the other request for new features. You do not then need a master-plan for everything in advance. Instead, you only need to identify the most important feature out of this basket to work on first. After implementing it, the feature basket and its evaluation might have changed, so you can adjust your path in the light of new insights.
In contrast, the master-plan approach is probably somewhat faster, if the requirements do not change much during its implementation, because you might be able to cut corners.
Since you seem to be rather uncomfortable to choose between the two options, I would take this as a strong indication that you should not miss out on the flexibility provided by the first approach.