This is the biggest one. I have seen many, many projects held back by the idea that they need eight nines of reliability and a geodiverse HA cluster before they can even start, where a single server with a half-decent backup plan would be more than enough.
Good security from the start
You don't need that either. You absolutely should think about security but it's by no means necessary to succeed. And really, backups and letting someone else handle payments will usually make it impossible to fail catastrophically†.
I consulted on a project pulling in 6 figures that stored bank account routing info in plain text and had zero source code control. Extreme example but proves your point, I'd say.
Cryptocurrency disasters are largely a result of the same poor practices we see everywhere, and there are more non-cryptocurrency projects than cryptocurrency ones.
>This is the biggest one. I have seen many, many projects held back by the idea that they need eight nines of reliability and a geodiverse HA cluster before they can even start, where a single server with a half-decent backup plan would be more than enough.
This seems weird to me because I'd gotten the impression, from reading around, that it was more often a problem that someone's servers weren't ready to handle the throughput due to not enough servers, not being written scalably from the start, etc. And I've seen this happen a ton of times with people's new web apps that they post to HN or reddit. It even has a name over there, the "reddit hug of death" when it's overloaded by the new demand.
In 99.9% of cases, a $5 VPS would have been able to handle the Reddit/HN traffic, if only it were configured better. If you "yum/apt-get install httpd" and call it a day, your default configuration will cause Apache to spawn more processes than there is available memory as soon as you get more than a few visits at once, and the disk swapping will kill the box.
If you set reasonable limits for the number of processes/threads/connections to keep them within the available RAM, then most sites will have no issue with thousands of visitors per hour. Here's a screenshot of the real-time analytics for my blog on a day it was front page of HN. That was a WordPress site, with no caching, on Linode's 512MB VPS (the cheapest plan). The server barely registered any load at all.
I also launched my web analytics startup on a VPS. It was handling millions of visits per day before I rented the first real server. You can absolutely have thousands of users, thousands of dollars in revenue, and a $20 hosting bill. Sometimes that's all that's required. Plan for what you're going to do when you outgrow the hosting, but there's no need to buy hardware you don't need up front.
Performance will depend a lot on your application & database, but it shouldn't take more than 10 minutes to get some rough performance numbers. Try pointing the apache-benchmarking tool `ab` at your site. There's some great tutorials around for the uninitiated:
http://www.cyberciti.biz/tips/howto-performance-benchmarks-a...
If your site is behind a login screen, you can manually login from the browser then copy+paste your session cookie into the ab commandline.
> It even has a name over there, the "reddit hug of death" when it's overloaded by the new demand.
And the OP's point is that even if this happens, the cost of trying to overcomplicate things by adding HA, multi-tenancy, etc outweighs the cost of just getting the app into people's hands. We have this innate fear that overloaded our servers is the "worst thing ever". It isn't. If your server gets overloaded, that's a good problem to have.
The most important - and most forgotten/ignored - part of a good backup practice, is actually checking that you can restore the backup successfully. Ok, it's slightly less important than actually backing up at all in the first place, but only slightly.
You won't believe just how many organisations will have an automated script for a daily/weekly/monthly rolling backup of their database, but won't have any procedure to restore the previous days database to check the backup procedure went ok!
At the most basic, it's just another automated script on a spare box to ensure the restore returns ok. But people don't even bother with that...
Word to that. I was contracting once and I asked about the backups. Someone was diligently changing the tapes on a daily basis but the backup had actually been failing for months. How we laughed...
On small websites, I use git to track /etc and /var/www (where the webapp code is installed).
5 years ago, I would have recommended to rsync the entire server daily. But nowadays it's a lot easier to snapshot an EC2 instance daily. For the database, just use RDS which handles point-in-time snapshot for you.
If you're a developer with little linux experience, don't try to play the sunday morning sysadmin with fancy bash scripts on your startup. It takes a lot more time and resources to keep a system in good state than you can foresee.
This is the reason for idempotent server configuration via Ansible, Chef, Salt, Puppet, or even better NixOS. Backing up a deployed application is kind of silly when the tagged releases should be sitting in your source control and that the press of a button have an entire server built and configured from scratch that is identical to the one you need. Then storing that configuration in source control.
Backing up configuration files and what-not is also pretty silly and indicative of bad devop practices.
The database should be versioned and maintained with a migration tool. So the only feature of the database that needs backing up should be the data it holds - live replication servers that can act as background backup slaves are perfect for this.
The only stuff you should be backing up on your servers are the latest log file rotations, user-generated data in the database, and any critical files that were also generated / uploaded by your users (but technically, you should be storing those in S3 with duplicates in another availability zone).
One other thought: people usually don't think to encrypt their backups. Duplicity + GPG + S3 is what I use right now and is super easy to setup with some fiddling. Once Tarsnap becomes a bit more professional I'll be moving all of my server backups to Tarsnap.
> So the only feature of the database that needs backing up should be the data it holds - live replication servers that can act as background backup slaves are perfect for this.
Replication won't help if a "drop table users;" happens. You need point in time recovery.
You may want to backup log files and uploaded images/files.
The backups should be stored at your main service provider and also at a different unrelated place, so if AWS or whoever deletes your account, your backups aren't toast.
You also want an automated system for monitoring that your backups are happening and that you can restore from them.
If encrypting backups, don't forget to backup your encryption keys.
That's what I meant by "background backup slave". The slave can handle point-in-time backups which is better than doing dumps or hot backups on the primary DB server.
One thing I would add to this is start writing tests from the get go. Any language you're writing in offers a lengua-franca Testing frameworks, NUnit, Gotest, RSpec, PHPUnit etc - just do it now.
Much later down the line when you start finding harder bugs you wish your basics were tested and verified. It's _priceless_ to run your test suite and make sure everything is kosher after a change. This is something that took me years to put into motion with my projects despite reading about it online.
Set up a build server on your own VPS or something like https://www.codeship.io/ and have it hook into every commit and run your test suite, if all green, deploy to production. Saves time, thus saves money.
We added test suites after we were making money / people had to rely on our software. I think doing it before is kind of a waste of time... because who cares about well tested unused software.
I'd say add them in after you have enough to pay one person full-time.
I agree with randall. Tests ensure that you build your software right, as opposed to building the right software. A large test suite impedes how fast you can deliver new features.
We wrote tests for PlaytestCloud only after we acquired the first paying customers.
The tests only ensured that customer-facing routes would not crash. It was a good balance to ensure that we could move quickly while ensuring that we didn't introduce catastrophic bugs.
I have to agree with that. Tests are an investment in QA. Prioritising that before you have a product-market-fit is probably the wrong priority (Of course, depending on the specific scenario).
A lot of thought leaders have been promoting testing like crazy the last couple of years, with the result that some people treat it like it's essential, when it rarely is.
Putting off testing until you show traction can be a slippery slope. Writing tests early on can have many benefits including: better architecture/design, confidence the code performs as expected, regression testing when adding new features, ability to more quickly add new features because of the good design, etc.
If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. This can easily lead to never actually getting around to writing that robust and practical test suite that is really necessary in the long term. Note that I also say the test suite should be practical (for some definition of practical which may vary from engineer to engineer). For example, 100% test coverage may not be useful, determine which parts of the code MUST be tested and which parts are just diminishing returns, etc, etc.
> If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction.
What I've done on a couple of occasions was to tell the nontechnical stakeholders that automated tests must be added before the web app framework (or whatever significant dependency) could be upgraded. In the context of such an upgrade, they could understand the benefit of a test suite, and they signed off on it.
It depends. There are 4 situations I can think of where writing tests is essential:
- mission critical code
- before refactoring
- people working on a codebase they don't understand completely (changing X might break Y)
- implementing complicated algorithms
In other situations, it's a almost a matter of taste: There are people who claim that writing tests will actually make you develop faster because you'll spend less time debugging. Also writing unit tests sometimes can make you think more systematic about all the edge cases an api needs to support.
So much this - in the past I was very stubborn when it came to writing tests, I was like "meh, why waste time on writing tests when I can write new functionalities in that time?".
Now, I'm quite the opposite - whenever I add new functionality, I write as much tests as possible - it makes life so much easier in the future. Yes, sometimes it can be irritating when you change one line in your code and you have to fix 10 tests, but the peace of mind when all tests run successfully after each change in code is priceless.
The key thing here is "in the past I was very stubborn when it came to x". This probably happens with most people so think about why you were stubborn about x in the first place and why it was the wrong choice to maintain that opinion until you finally changed it.
The amount of time saved depends on a number of factors. Writing a test suite before you know what your product even does can be counter-productive.
I never write tests until something is launched and it looks like anyone will be using it. There's no need to have test coverage for software that's going to be completely torn to shreds every couple of weeks until that first spark lights in the eyes of a user who finds the value proposition you've been searching for.
Unless you have the luxury of working with a full team and have plenty of time to kill (read: money to burn) you're going to want to cut as many corners as possible. If it is a fast moving new market it could save valuable weeks to skip out on a number of 'best practices'. You would be astonished at the number of products launched without a stitch of what would pass muster on a more mature code base.
The goal is to find something that people want, not to make robust software. That comes later. Pretending like there aren't up front costs to writing and maintaining tests is absurd.
You'll also find that if you're sticking to functional and stateless design patterns that your code is incredibly easy to reason about. Ditch the OO patterns like observers... Anything where new instances of objects are created, anything where you can't literally serialize the state of your running application, restart it, and get back the entire state you were just in...
People tell me that tests force people to reason about their code in such a manner. I think that reasoning about your code in such a manner is the really important part. You end up with code that you never need to step through or pry apart in a REPL. It just works (TM). I dunno, I've been writing application code for almost 20 years now. I've learned from a lot of architectural and implementation mistakes I've made over the years. State and side effects are the fucking enemy. All of the testing in the world isn't going to fix your ill conceived understanding of whatever new problem space you're dealing with.
I also find tests make the most sense when there are multiple developers working on a code base. A single dev isn't going to benefit as much from the cost.
And yes, again, tests do have a cost. It is absolutely ridiculous to argue that they don't.
And ditch the objects. They make no sense outside of a Smalltalk or Self environment.
After you launch and people are using it, after you've got a few developers working in the code base, after the product has actually stabilized to a set of more or less concrete specifications, THEN write your tests.
If it really is the frontier then cowboy coding is just fine. :)
The west wasn't won with prudence, it was won by taking risks and moving quickly. You're not the only guy with dreams of building that railroad. Someone else is already driving stakes in to the ground. You can go back and build a better bridge, a more efficient path through that valley, or a safer incline AFTER the line links up. The intercontinental railroad was a mess for decades after it was built but that didn't matter because the utility provided was immeasurable.
If you're just building another commuter rail in a busy town, well then I can't relate at all. Use your TDD mumbo jumbo. I'm a start up guy, I'm a cowboy, ON A STEEL HORSE I RIDE. AND I'M WANTED, DEAD OR ALIVE.
BTW, I have plenty of start up friends who successfully start new projects with tests. I mainly wrote this because I wanted to quote Jon Bob Jovi at the end there. :P
We have been using codeship for about 4 - 5 months and we are really happy with it. The guys do a nice job. Moreover, they spin up DB instances that can handle our integration tests. It really has been a time saver -- not having to maintain our own CI server.
Wait, what? I was with him until that. Using a CSS reset is part of CSS 101, I would never dream of starting a project without one. It isn't a "complex dependency", it simplifies cross-browser issues greatly. Putting this on the list is simply... bizarre.
The problem with reset.css is that people often use reset files made by other people without understanding what they do. For example, lot's of people use https://github.com/necolas/normalize.css, without realising that it will turn off automatic text size adjustment on the iPhone. That's fine if you actually test on the iPhone and make a mobile specific stylesheet, but if you don't, this will make the experience worse for iPhone users.
So if you are going to use a reset.css file, you should do some research. Check on google what other people are writing about reset.css files, read comparisons of different reset.css files, test different reset.css files on different browsers, etc. But then you've wasted an afternoon NOT BUILDING YOUR PRODUCT.
If you just accept that your website is going to look slightly different in different browsers, you will realise that you don't need a reset.css file, and you will save a lot of time.
I've used a CSS reset in all my projects (both work and personal) for the last 7 years, and I agree that it's not mandatory for a successful product.
The CSS reset is a convenient tool for the visual layout only. It helps with browser consistency and prevents margin/padding/font-size issues mostly, but it won't turn your idea into a successful product. I think that's the only message the article meant to convey.
He says that you don't need that to make a successful webapp, which is true as you can make a successful one without it. I understand the post more in the line of focusing on whats important and not focusing that much in what is not.
I have never used any reset.css file (I'm more of a backend developer), but I find this idea very interesting. Is this reset technique often used in modern web development ? Any feedback on this ?
"Professional" web developer here. Indeed the reset technique is used very often. Browsers often implement default margins and padding differently. A CSS reset can give you a more reasonable baseline to work with.
These browsers usually have reasons to have their own styles. Sometimes they are there to be consistent with the base OS (drop downs, buttons, etc) or they are there to best suit the format that the browser runs on small screen (phones), large screen (desktop) etc or to take care of device input types (touch screen devices would have larger buttons by default whereas pointing device doesn't need to have large buttons). I think it's best to let the browser decide what it wants to decide and build our app around browser differences instead of forcing our own design down browser's throat.
I think the problem is manly IE vs Chrome vs Firefox.. (and of course Opera). Example: Why would you want to have by default a padding of 10px in IE, a padding of 5px in Chrome, 7px in Firefox and 0px in Opera? Of course is easier to make a default for all those browsers to 0px or whatever you want.
Are you suggesting that using HTML5 Boilerplate is a bad idea? Because no, no it isn't. That is an insane assertion. The number of weird idiosyncrasies or browser specific problems that WILL come up with any web app that I've fixed by just saying "hmm, wonder if I put in HTML5 Boilerplate" are insane. It creates 0 technical debt, you will always be happy you started with it, and it is fantastic.
I do no understand the big about reset.css either but I guess I"m willing to listen? Reset.css has also been a lifesaver.
For a blog making a really important point (don't just use Angular because you've heard of it, use what gets shit done), suggesting that boilerplate creates dependancies that you will regret having seems out of place.
The current version of HTML5 Boilerplate includes several things in the header that probably aren’t exactly what you want, particularly if you’re supporting mobile devices.
It loads 4 distinct JS files. One of those is Modernizr, which is loaded at the top of the page and will therefore block, and there’s a custom class on the HTML element to go with it.
It loads 2 distinct CSS files.
It inherently has potential security and privacy issues that come from using any third party servers, in this case Google Analytics and attempting to load jQuery from their CDN.
Likewise, it has dependencies on some third party scripts, both Modernizr and the ones for Google.
And it contains an unprofessional nag message for users of IE8.
This is not a criticism of HTML5 Boilerplate. All of the defaults mentioned above might be a good fit for some projects, even many projects. However, none of them will be suitable for all projects, so the moment you start from HTML5 Boilerplate you almost certainly have some technical debt to pay off, just like any other template or framework or scaffolding system.
How did only adding parts that are relevant to the current project become some sort of “optimization”? There is more work to do if you start from someone else’s boilerplate that has lots of parts you don’t want, because you have to actively delete things that you need to replace or just don’t need at all.
In any case, some of the defaults in HTML5 Boilerplate can have real negative consequences if you just use it without fixing them. If your market will be using mobile devices a lot, or tends to have limited connection speed for any other reason, then making half a dozen extra requests before you even start doing anything interesting can have a significant impact on performance. Playing around with viewport settings can have significant adverse effects for usability if you don’t know what you’re doing. That little message about IE8 that isn’t going to show up on the recent browsers your developers usually use is going to get you in trouble with a client one day if you develop a lot of intranet sites and forget to remove it.
Reducing the number of includes in the header is very much not premature optimisation. On a phone with poor connectivity, a single blocking Javascript in the header might cause a one second delay (or longer).
CSS frameworks, boilerplates and reset.css could probably be condensed into a single point. (HTML5 boilerplate already contains some form of reset.css anyway)
I guess some people just like to write their frontend code from scratch...? It's funny because the author wrote Zepto, of all people he should know about abstracting away cross-browser concerns.
Right? Man I feel like I'm missing something huge here if somehow reset.css and HTML5 Boilerplate are creating technical debt for me. I think I've launched at least 10 projects using it and I've never once had to say "oh that's a weird thing that HTML5 boilerplate does, here's how you compensate for it" like you have to do with Bootstrap or Foundation or things that DO create debt.
I think the point was that they weren't completely necessary, and it would create a dependency on their continued use? I'm not sure, but that's what I got, and I don't agree. NOT using CSS frameworks creates a pretty radical dependency on NOT using them in your design going forward. Sometimes the costs of not doing or using something create a lasting debt.
There's an alarming stench of NIH in some of the authors points, co-mingled with some more salient points about not over-engineering up front.
Great piece. I realize now that I'm more or less clueless about one of the things mentioned there:
> An understanding of tax laws in your country
How does one learn this? Is there a book you guys would recommend?
I think in addition to tax code, learning a bit of legal stuff is probably necessary too. And for that, grellas's guide is probably handy: http://www.grellas.com/faq_business_startup.html. Learning about accounting would be a good idea too, I'm also clueless there though - any recommendations for learning that?
I suggest an obvious but effective policy: when you need professional advice, speak to a professional.
The first time you need a certain kind of legal document — terms, privacy policy, employment contract, whatever it might be — speak with a lawyer.
When you set up your company, find a decent accountant who can get the proper structure in place. They can tell you the basics about what records you need to keep and when you’ll need to do things.
After you’ve done something the first once or twice, you usually have a reasonable understanding of what the essentials are, and you can probably do more of the work yourself to save time/money. The professionals can then become more advisors and reviewers than the people doing routine paperwork.
I also strongly agree with 'jakobe about finding professionals who are used to working with small companies, preferably by personal recommendation. It’s much more than just pricing: the whole way they work is often very different to how bigger accountancy and legal firms who are used to working with bigger companies work.
As a final tip, in most places there are organisations that support small businesses that you/your company can join. These usually have a modest cost, but IME membership can easily pay for itself many times over. Some useful services they might offer that save you time and/or money include providing templates for common types of legal document (which you can use as a starting point if you’re drafting yourself), providing legal and/or tax helplines (which you can phone when you just need five minutes speaking with someone who knows what they’re talking about), and producing general guidance on things like contracts, tax, and insurance, with a focus on issues affecting small businesses. You might also find you can get more attractive pricing on things like business supplies and insurance through such organisations, as they have much more bargaining power collectively than any single small business has on its own.
In my experience you don't need to know much about tax laws to run a small business. Find a cheap accountant* , and he'll tell you everything you need to know about taxes in two hours.
* When you are just starting out, it makes a difference if you pay someone 300€ a year to do your taxes, or if you have to pay 1000€. Stay away from the big companies. They will charge you for every phone call. Ask other small business owners for references.
Hiring an accountant was a godsend. I had just moved to a new city and did not know we had a business property tax here, or that the city itself had their own business licensing requirements (even for work-from-home freelancers). Not only did my accountant quickly get all of that taken care of, they also found more deductions in my taxes than I was paying them. It paid me money to hire an accountant.
Technically, yes, one could navigate all of the forms on their own and get even more tax savings, but that is only the case if you don't value your time. Since I charge my clients by the hour, and filing taxes often takes several hours for us in the United States, having an accountant also meant I could work without worry and make money instead of having to take a day off from working or stress myself out on my regular days off.
Hire an accountant. Do it right away, you give them a retainer and they'll have a price sheet of services they offer. They'll ask you what your goals are, just tell them you are interested in making sure you are in full compliance with the law, but don't know what you're doing. They deal with customers like us all the time. They have it streamlined and know exactly what to do.
It continuously surprises me how little programming knowledge is actually useful in this field where we call ourselves programmers.
Even if you arent building your own startup, knowing how to tradeoff big win features over engineering resources, understanding the risks of X new tool over delivering a product, being able to communicate effectively and work within a team are very typically far more important than raw programming talent, brilliant engineers will always be needed especially on big projects, but you can get a long way with a little programming talent and a lot of a common sense approach to delivering a product.
An OK list of tools. Two I would add at the very top, though:
1) A problem your app solves
2) Users of your app
Seriously, the other items on the list aren't necessary until these two criteria are met. Then, and only then, will the elements of that list be necessary.
Why so many articles about how you don't need the cool hip new technology to be successful? Surely this is a news site populated by people who like playing with cool new technology.
I don't want to be successful it sounds stressful. I want to enjoy hacking maths and code.
Great article, I often see myself looking to use the latest thing as opposed just creating a good app.
One thing I disagree with is "don’t anticipate 'potential' problems". Preparing early for problems which may occur later is very important for obvious reasons.
Maybe a little bit off topic and probably depends on the app, but how sane is developing a web app/UI that works for mobile/desktop these days? or is it just better to develop for desktop and mobile separately?
I build web apps that are mainly for desktop use, but I make sure they're as polished as an HTML5 fronted can be for iOS and I test on android to make sure it's good there too.
We have run into issues on layouts where the project leader wanted one thing, then changed his mind two or three times (and this was after being implemented) so that view is a little tough to work with now, but generally speaking if you have a clear picture of what's important to your user it's trivial to present one experience to mobile users and a very different experience to desktop users based off the same markup.
The key is is tilling your markup down to the minimum to suit both layouts. When you have too much markup it gets tougher to make it responsive.
Too bad he mixes great suggestions with awful suggestions. I use those 'CSS frameworks, boilerplates and reset.css' specifically because I want to give all my customers 'good UX flow and visual design'. That would be a lot more trouble without it, reinventing a lot of wheels, some of which are hard to reinvent.
How on earth can you give a list of goals to achieve and then banish technological measures that have the primary aim of achieving some of those goals?
He's not "banishing" anything. He's saying there are some things you NEED, and some things you don't. You can have a successful webapp without using a CSS framework. You can't without solving a real, well researched problem.
You can definitely have very successful apps/services without decent UX, design or researching the problem. The internet is full of examples of each of those.
But you don't need CSS frameworks for the sake of CSS frameworks. Given how some of the "don't" entries are written (NoNoNoNoSQL ...), I read them as referring to the bickering about using gulp over grunt over make over shell scripts and the like.
At some point you've made a successful web app, and then you need to make a successful business and supporting services, and you need to minimize costs and meet SLAs that are required to secure your revenue.
So the subset for a 'successful web app' is a useful distinction to get started, but the condescension implicit int he second list just comes off as ignorance.
I thought this was going to be a little deeper, but it's physically the TOOLS (software, skills, knowledge) you need to make a web app... successful or not really has nothing at all to do with this.
And he forgot a really important one.
1) A genuine interest and passion for the service you are building and will be spending thousands of hours working on.
Required for a successful VC-funded shooting-for-the-moon startup, maybe. Not required for a successful web app. I paid off my student loans and put a downpayment on a house with a "add reviews with star ratings to your online shop" app. I have no passion for ratings widgets. I also now host contact forms for ~1 in 20 Shopify stores; I have no passion for contact widgets. They're just products, that happen to solve problems for some people that value the solution. Solutions to most business problems aren't complicated, thousands-of-hours undertakings.
What Dan said. Passion doesn't have to be for topic area. Passion can be for helping people, for solving problems (whatever they are), for seeing your work in the hands of people who benefit from it, for creating a comfortable & happy life for yourself & your family.
"Passion" is a cheap word. It can mean anything. But it's taken to mean "something that overpowers your sense of judgment and reason" in the startup world. Doesn't have to be so.
I wonder if it's safe to add "big-iron client-server database" to the list of things you don't need. One of my friends is running his production web app on SQLite.
it may be better to get feedback upfront instead of spinning your wheels on collecting money. idea validation seems quite important, at least in the beginning.
But if you aren’t collecting money, then you literally don’t know how much any feedback you’ve got is worth.
Even if their comments are well-meaning and made with no intent to mislead or deceive, what people say they would do in a hypothetical situation and what they actually do in a real situation can be very different, particularly where spending money is concerned.
I don't like how every single post on unicornfree tells you that the conventional wisdom is wrong, and to learn the truth you have to sign up for their online seminar.
Every post I write says that conventional wisdom -- e.g. creating a product people want & need, and charging for it -- is right. And most of my blog posts are full of value, and actionable things a reader could do right there, for free:
People who want more, have more money than time, who value an expert demonstration, and live exercises graded by a teacher… take my class. But I've known many people who had more time than money who implemented the principles in all my free content and turned that into valuable businesses.
This is the biggest one. I have seen many, many projects held back by the idea that they need eight nines of reliability and a geodiverse HA cluster before they can even start, where a single server with a half-decent backup plan would be more than enough.
Good security from the start
You don't need that either. You absolutely should think about security but it's by no means necessary to succeed. And really, backups and letting someone else handle payments will usually make it impossible to fail catastrophically†.
† Some exceptions apply.