Do you use best practices when prototyping?

I have been writing about Micro SaaS to 25,000 subscribers every week. My best suggestion would be to stay away from the best practices in the initial phases. For example, things like writing unit test cases, setting up multiple pre-production environments, containerizing applications, performing point-in-time backups, etc. can wait. I'm not suggesting you totally ignore the best practices, but these can wait until you get a few users. Priortize what is required based on which stage of starup you are in.

In the prototype phase, don't worry too much about these. Rather, spend time building the simplest prototype and spend more time talking to users or building waitlists.

Remember - "premature optimization is the root of all evil"

I write tests for things that are faster to run tests that to click through the ui. Billing webhooks are a good example... takes you like 30 keystrokes to fill out a cc form, only two to run the test.

Test for tricky things that have bad side effects, like sending DMs, emails, and paid api access.

Time zones... I always test time zones :(

Security is never skipped, but let's be honest, I'm not building an NSA hardened software system... just making sure that users should only see the things they should see.

Everything else, meh.

At some point in the future, if it's broken or to hard for anyone to understand, it will be rewritten in full, with tests, documentation, comments, etc.

The best practice is to realize there are no best practices and you should do the minimal amount needed for the job. Then as you scale you can apply better practices...

Most who follow "best practices" are just overthinking or perfectionists. That in itself hinders creation.

My prototyped code has

1. Commented Code
2. No Unit Tests
3. Poorly Named variables
4. Duplicated code
5. Poor design
6. No performance optimization

:)

I could never get a pull request approved in my 9-5 software dev day job
if I missed any of the above. The code quality of my work in 9-5 job is 90% better than
code quality of my work in side hustle prototype.
The difference in quality is mainly due to time constraits
I use chatGPT a lot to refactor and clean up my prototype these days

Absolutely not. I just try to get to market as quickly and as simple as I can. Of course, maybe this would change if I worked with other devs on the project (but I doubt much).

Let me tell a story. I started some projects, but never finished, until some days ago. I've released a micro project.

I wanted always clean code and some test coverages and so on for my backend. Well, technically the code was okay, nothing about to complain.
I wanted a good local dev environment and so on

But

1. You waste time with test coverage and setup the stuff and so on.
2. Simply implement the stuff you need and don't look if it's good coded or not.

With the time you didn't invest in clean coding and so on you can invest in marketing.

That doesn't mean you should code crap. It should be working and in a stable version. But don't waste your time with refactoring. Even call it tech debt, but you can do it later. Then when your product makes money.

That's something I had to learn.

I use the best practices that I believe in and avoid the ones I don't

Like for landing pages I'll whip em up in 30-60min and not look back (after getting feedback I iterate)

For no-code apps I do the same as landing pages

For code-based apps it's a little different. I have to make sure that at the end of each phase of the development the code is clean and scalable (with tweaks) if not then I'll really regret it later (know this from experience)

For code I have the following levels:
-Wow it worked I'll worry later
-Hard coded glue code I knew would work but I didn't want to write it like that
-"Isolated Code" - code who's feature is separated (in case another feature breaks this one won't unless it's connected)
-Code I thought would work I believe is scalable
-Code I've scaled

Hope this helps

This is a great question that many startup founders and builders grapple with. It's tempting to cut corners or skip best practices in the early stages of a project when resources are limited, but this can have consequences down the line.

In my experience, it's important to strike a balance between implementing best practices and being mindful of costs and resources. It's okay to prioritize certain best practices over others based on your specific situation and the nature of your project.

For example, if security is a top priority for your project, you may need to invest in more robust infrastructure or take extra steps to secure your code, even if it comes at a higher cost. On the other hand, if you're building a prototype or MVP to test the market, you may be able to make some compromises on best practices in order to get your product out there quickly and affordably.

That being said, it's important to keep in mind the long-term costs of neglecting best practices. Cutting corners now may save you time and money in the short term, but it could also lead to technical debt, security vulnerabilities, or other issues down the line that is even more costly to address.

Ultimately, the key is to make informed decisions about which best practices to prioritize based on your specific needs and constraints. And as your project evolves and grows, it's important to regularly reassess and adjust your approach to best practices in order to ensure the continued success and sustainability of your project.

No, I prefer to launch my product as quickly and easily as possible without making it too complicated. However, if I were working with other developers on the project, this approach might change.