3 ms·
So, I've been working a bit on a simple RSS reader in a spare hour or two over the last few days, just to experiment with some ideas, and one of the things I de
by wwweston 14y ago
So, I've been working a bit on a simple RSS reader in a spare hour or two over the last few days, just to experiment with some ideas, and one of the things I decided to do at some point was create a small backend service that just generated a gibberish feed -- ordered dates with news item frequency I could set, proper RSS, but nonsense text and a pictures of/links to cats.
This was after I already had a "real" backend (could grab/merge RSS feeds), but I still found it useful in focusing on some front-end features, and I wonder if I might even have been farther along from a prototyping standpoint if I'd made that approach from the start.
If this is true for some problem domains, my guess is that it's possibly more true for those (such as feed gathering) where the backend tech issues are mostly simple or solved problems and most of the novel work to do is in the realm of UX.
- mcintyre1994 14y agoI think, to generalise a bit, you should probably work on your hardest problem needed to launch. If that's an awesome UX, you should probably make sure that's possible, and especially with front-end stuff validate that it's usable. If your backend has unsolved problems that are needed for launch, you probably want to make sure they're solvable before you spend ages implementing the frontend.