That's the best of both worlds: a reimplementation of an existing project. You have all the freedom of a greenfield project, and you don't suffer from the "blank page syndrome" or writer's block the author talks about. Port the tests over, then rewrite everything, this time with a better architecture. [2]
--
1: Since someone is bound to ask, I am incorporating a Rust standalone app into a larger Elixir monolith. Because while static typing is nice, turning a Rust app into a highly-concurrent and highly resilient with native OS primitive (threads & co.) or, yikes, async, is masochistic when I have the power of the BEAM at my disposal.
2: Tongue-in-cheek here, I am well aware of https://en.wikipedia.org/wiki/Second-system_effect
Not only do you not suffer from the "blank page", you can are privy to all the mistakes made before. Of course, you're now open to make a bunch of new mistakes, but that's ok—there's still the benefit of tons of knowledge from the original project.
Furthermore, the Elixir ecosystem really helps mitigate that "too many tools" feeling.
Put everything in a container, stick it in a dedicated server at Hetzner, and Bob's your uncle.
I pay €35/mo for a 32GB RAM, 8-core, 2x SSD dedicated server with unlimited traffic. Elixir flies on that.
They charge €40pcm for an i7-4770, 32GB RAM, 2x SSD which can be bought for around €100 from any IT surplus (given it's around a decade old) and thrown in a libre/GPL colo at your local hacker space for single digits pcm.
EDIT: just the mobo, CPU and RAM is $300 on eBay. And let me know which hackerspace has a dedicated maintenance team, SLA guarantees, unlimited traffic. Apples and oranges. I'm trying to run a business here, not run a Minecraft server.
Should I really be penny-pinching on what is $50/mo? It's two pizzas, at current market rates.
Designing a robust/performant/reliable architecture right from the start is not "interesting", it is effectively impossible unless you have divination skills. At some point, your architecture will suck, and restarting from scratch is usually a bad idea, and that's when things get interesting. That is, fixing the mess you created, making something robust/performant/reliable out of something that is not, with the additional constraint of not breaking it in the process.
But you still need to start somewhere, even you know it will fail. It means you will essentially do a dice roll and hope for the best. Yes, the beautiful architecture you start with is nothing more than that. If you leave after that, not only it may not be cool for the ones who will inherit your mess, but you also won't get to see the hard (and interesting) part.
Of course, even though it will always be a dice roll, it doesn't mean your initial decisions won't matter. How fast will you fail? (failing fast is a good thing) How fixable your mess is? How will it fair after an army of monkeys tramples over the code? etc... These are questions experience can help you answer, but you won't get this experience by doing greenfield projects. You will get this experience by being in front of the fan as shit hits it.
So yeah, I understand the love for greenfield project. It is like a reprieve, where you can use that experience acquired during the time you were covered in shit, and try to make the best roll. To me, it is the comfort zone, but as often, the comfort zone is not the most interesting.
If you're working on a greenfield project there's a very high chance that your "robust, performant and reliable" is someone else's tech debt once people need different things from the system in a few years... And then the more clever that original work, the harder the rework.