I recently quit my job to start a startup, but this isn't my first go 'round. The first 8 years of my software development career I freelanced while I "bootstrapped my projects". I'll give you one guess as to how much money I made on my projects vs how much money I made contracting.
I took full-time work after it became clear my startup ambitions weren't panning out and suffered through that for 3 years. That was, however, enough time for a lot of very important lessons to solidify in my head. This time, I'm taking a far different approach, which is as follows
- put off coding for as long as possible. Every line of code you write before you validated that someone actually wants to use what you're writing is time (read: money) that you've thrown down the tube
- your big idea sucks by default, so don't come up with a big idea. Get as many meetings with as many people as you can (preferably decision makers) and ask them about the sources of pain within their organization. It won't take long to find a real opportunity.
- speaking of opportunities, be wary of anything that you're initially excited about solving. If you're excited about it, that means it's fun, and if it's a fun problem to solve, that means there are more people who are willing to solve it, which means it's less valuable to solve. Find problems that are painful and tedious to solve to guarantee your competition is minimal. After all, that's what people really pay other people money for - to avoid pain
- do the hard things first, which for engineers, is talking to people. The majority of your time should be spent learning about your potential customer. By the time you actually write a single line of code it should be painfully obvious exactly what needs to be built.
- Use old, proven tech. The biggest enemy you will contend with is your own desire to use shiny, cutting edge technologies. You want to use tools, languages, and techniques that have no "unknown unknowns". Use proven tech, but more importantly, use tech you're already comfortable with. You don't want to be finding and fixing bugs for other people's software on top of writing your own.
- If you don't trust yourself not to over-design, over-engineer, or in general turn your minimum viable product into a maximum viable product, pay someone else to write your code. Because you're not paying yourself when you write your own code, the tendency is to devalue the work, which leads to a higher likelihood that you will work on the fun but less important parts of the project first. If you're paying someone else real money to do it, you will make damn sure they only build an actually minimum viable solution to the problem you identified.
- Design comes last. There's such hyper emphasis on UX and design these days that it's easy to fall into the trap of thinking that it's the most important part of solving someone's problem. If craigslist survived for as long as it has by using the native web ui toolkit, your product likely can too. "Does it solve the problem" comes way before "does it look good doing it". The only exception is if you're making a carbon clone of a software solution that has a proven market but severe problems with design and usability (e.g. IRC being cloned by the more usable and pretty Slack).
- B2B, not B2C (but it sounds like you already know this)
- Avoid empty room problems. If your solution's effectiveness relies on a critical mass of users you will likely run out of money and patience before you get there. Only try solving these types of problems if you're willing to stick with the community building aspect for a sufficiently long period of time or are independently wealthy to begin with.
- You can freelance to pay your bills, but avoid relying on it too much. There's no greater motivating factor for creating a product that people actually want to pay for than actually needing them to pay for it in order for you to survive. Deciding which modern framework to use, how you're going to scale to a billion users, or tweaking your designs to pixel perfection will suddenly seem a lot less important when your rent is coming due.
- Find a co-founder. I know you think you'll be fine going about this on your own, but Paul Graham is right; there's almost no better measure for success in a startup than the presence of a co-founder. Running a startup can be likened to willingly accepting a bout of temporary insanity because it requires you to believe in a reality that doesn't exist... yet. It's easier to prop up that reality when you have someone with you to reinforce it. The goal is to turn that insanity into sanity by making that fantasy into a reality. Momentum, morale, and faith in the unproven are the most important and hardest aspects of a startup to maintain (again, not the code). You're building a cult, so find your first adherent.
Good luck!