Nothing here yet.
Nothing here yet.
Anurag Kanoria I chose Wyoming over Delaware because of expert exchanges like this one on Reddit . In the end, it depends on if you ever intend to turn this into something bigger or want a small self-operated and fully self-owned business. For that, WY seems to be the better choice. This is not legal advice. Just my experience and what I read on the internet :) Regarding pricing: I wrote a lot about pricing — please check out the articles on my blog for very detailed excursions into each topic. As a super-short answer, three options are usually effective (as most people go for the center price when there is such a choice), and it will allow you to figure out what the value metric is for your customer (what number goes up in your data when your customer makes more money). That should be the deciding tier split between those pricing tiers. Using competitors' prices is a good starting point. Depending on if your business is more elaborate (price higher) or a less complex but still perfectly usable product (price lower), you should use the prices in your industry as an indicator as to what people are willing to pay. A warning here, though: not every competitor in your field is a business. Competetive alternatives can take many shapes . Do your research into ALL the tools your prospective customers use right now, including tools that you wouldn't call competitors: notepads, post-its, Google Sheets… they all impact what people are willing to pay. Pricing is a constant experiment. Your initial pricing won't ever be "right" , but it's a starting point for those tests.
A developer is a scalpel. A founder is a swiss army knife. It's really as simple as that. As a dev, you're focusing on using technology to solve problems, one feature at a time. You — hopefully — can get into a flow state, create a mental map of the system you're working in, and then operate on it with surgical precision, solving a clearly defined problem. You might even have requirements and a well-defined solution state to reach. All of this stops when you're a founder. Your challenges are nebulous and often evade any chance of being defined. There are no well-defined states to reach, just running experiments that may or may not work out. It's often very much the opposite of coding: you have no compiler or interpreter to tell you if things will work or not: reality is that for you, and reality has horribly long compile times. The good thing about becoming a founder is that the elasticity required for it will broaden your mind. If you are responsible for the whole business, you start seeing the technical implementation as one of MANY things that need to be done. You reprioritize things. That often leads to more pragmatic choices: instead of building the business on the newest Vercel-based serverless stack, you might just go with a quick prototype built with Ruby on Rails because that is the language you know. Instead of reading through the documentation of the latest k8s offering, you run your little web app on free Heroku dynos for the time being. Being a founder teaches you to juggle — which is the opposite of a flow state. I found that incredibly hard as the person building tech in my own startup. I had to be there for customers AND build features for them. It was the worst when there was an emergency: I had to fix our deployment while telling hundreds of customers through chat that I was working on it. But I got through it, and I see other developer founders get through it every day. It might sound scary, but it will turn you into a much more pragmatic developer. And, if you choose to build a business, you will use your technical skills — when you take the time for that — to build something that is valuable and owned by yourself, not some employer somewhere. That is incredibly motivating.
Almost all learning in entrepreneurship happens experientially. You can read as many books as you want, the knowledge you gain from that will pale in comparison to actually going through the motions. However, there are ways to prepare you for your clash with reality. And that is where info products such as books and courses shine. They won't stop you from making mistakes, but they will show you where the tripwires are — so that when you run into them, you know how to untangle yourself quickly. The best antidote to your own ignorance is to seek the company of your peers: surround yourself with other people at the same stage of their entrepreneurial journey. Exchange your struggles and challenges with them regularly. The Indie Hackers community and the whole of Entrepreneur Twitter are great places to find like-minded people with similar problems and aspirations. It's pair programming at scale. If you need smaller groups, look for masterminds. There are many small communities like the Weekend Club that allow founders to stay accountable while helping them build relationships with each other. Those sessions are the tacit knowledge transfer opportunities you're looking for.
I have registered a (Wyoming) business using Firstbase, and it was a breeze. Mind you, I am also an investor in the Calm Company Fund that has funded Firstbase. I wanted a US business, and now I have one. Why did I want it? I wanted to make sure my liability was covered. It makes it much easier to invoice enterprise customers, build business partnerships, and eventually hire people. It also comes with a lot of little goodies, from free AWS credits to a Mercury bank account — and you need that stuff when you start a new business, anyway. For a B2B business, I highly recommend creating a business entity. In fact, when I co-founded FeedbackPanda back in 2017 with my partner Danielle, I made sure we had a business entity (German GmbH, an LLC equivalent) before we got paid by our first customer. I wanted our business books to be independent of our personal financial records. I've seen too many people running into audit problems with those hilariously small first few months' worth of revenue. Strong separation from the start. Having a company like this also helps you work on new business ideas. The " studio model " may have originated in the VC world, but it works for bootstrappers who are building a portfolio of small bets as well. Build your business from within your Delaware LLC, and if it flops, build another one from within the same company. No need to go through the formation of a business all the time. Just to clarify: depending on where you reside, you might want to consult a local lawyer or tax advisor. Your local regulations might make this harder depending on what they look like. I have not done anything with trademarks for myself. I don't have any advice here on this issue, but I'd gladly look into this for you. Reach out to me on Twitter, and we'll ask my audience there together.
I write my books in public. Every week, I write an article on a topic I want to tackle in the book. I work on that as a standalone article, written over the course of a few days in a simple Markdown document. I work in reader feedback after publishing. Over time, I collate my articles into a book manuscript, filling in the missing pieces. When it comes to visuals, I usually find help. I know a lot of great illustrators on Twitter, and I pay them to visualize my work — as contractors. I wrote about my technical approach to writing on my blog . It's really just markdown, funneled into Vellum , which exports eBooks and a print template. And regarding Canada: moving here was a great idea. The air is fresh, the BBQ is tasty, and I am finding a lot of time to think and write. Much less stressful than living in Germany's biggest city. And yes, less bureaucratic, too. The North American spirit is alive and well here :D
I think we're still in the "Wild West" stage of web3. Technology-wise, it's quite complicated to implement and requires a lot of keeping up with bleeding-edge tech. This is great for learning new protocols, languages, and paradigms. It's really not that great for trying to build a sustainable business — there's quite a lot of uncertainty. Bootstrapped businesses usually are built as small improvements over existing solutions. Web3 has the potential to revolutionize how we deal with ownership and community. We'll see bootstrapped businesses in this space in the future, but if you want to build a successful indie business now, you might want to go for a technology that doesn't change every few weeks.
If you're having trouble with one particular idea, I'd suggest taking a step back. There are two ways of building a business. The product-first way starts with an idea, then you build something, and then you try selling it to the market. That's what happens on ProductHunt many dozen times a day. And most of these products flop. They're solutions looking for a problem. The audience-first approach, however, focuses on finding your ideal target audience first, making sure it exists, and then learning about their problems and challenges by embedding yourself in their communities. From there, you listen, observe, and look for interesting problems to solve. THEN, and only then, do you start thinking about your idea. It's much easier to get someone excited to help an existing group of people. If your friend has a hard time committing to your idea, take that birds-eye view together and commit to "spending two hours together, analyzing the existing problems of one particular community." Maybe even better, spend two hours brainstorming all the communities you can think of, and find one that both of you would love to serve and empower. From there, look into the problem space, and come up with an idea together. The best ideas are CONSEQUENCES of this process. They are also the most validated, as you already know who you'll be selling the product to, and you're sure they have that problem — because you found them talking about it in their communities! If you can do this together, you'll both be equally motivated.