40
60 Comments

It's taking me a year to launch. Am I doing everything wrong?

It's taking me almost a year to launch. I'm coding every day, weekends too, and it's my only job. For context, I'm a self taught developer, who never had a job as a programmer. This might slow me down, as I learn everything from scratch.

But I think theres more to it than being self taught. I'm not grasping how to ship faster. What features are unnecessary? How do you cut corners?

There are pieces of my app I didn't even know you could CONSIDER leaving out.

Example:
Last week I implemented the "delete account" feature on my (not-yet-launched) app.

I read about deleting user accounts, and found complex laws involved about keeping customer data (ex if you do a soft delete, this could be illegal). So I messaged a fellow indie hacker, and asked what he did for his "delete account" feature.

But, he didn't HAVE a delete account feature. I was surprised. I thought this was a standard basic feature you must have to launch.

He also said that if he were to add it, he would just have a fake "delete account" button that emailed him. When someone needed it, he would delete their account manually.

I had not considered either of these options- leaving the feature out completely or making a fake button. I sort of knew this was something you could do in an mvp, but didn't think that I could put something that hacky in a beta launch.

It made me wonder what else am I doing that's extra? I hear "ship faster". But how? What are some concrete ways to ship faster?

In addition, most people around me are software engineers. Software engineers seem to give advice completely counter to what entrepreneurs recommend.

Software engineers will tell me to code something in a way that considers the edge cases. Coding for the edge case often takes longer and leads to less usability for the average user, and more usability for the edge case user. I'm only realizing this now, after already implementing so many features in this more "software engineery" way after getting advice from well-meaning software engineers who are not indie hackers.

How do you find good advice on building an indie app? How do you figure out how to ship faster? What are some concrete ways to ship faster? Are there any good resources that illustrate examples of shipping faster?

Signed, A totally clueless indie hacker.

  1. 24

    You're probably a bit far along for this advice, but I think it helps to just start smaller. Build something simpler and less ambitious.

    For example, if you've got nights and weekends open for a side project, build a weekend project instead. If you think you've got time for a full app, build something side project-sized instead. If you've got a small team of people, build something you think one person working full time could do.

    The goal is to always give yourself a substantial amount of breathing room, because you're going to need it. Not only will features take longer than you expect to add, but there's much more to your business than product development. Ideally you'll leave at least 50% of your time free for marketing, learning, and operational stuff, too.

    1. 1

      Thanks man. It might be too late, yes, but still this is still helpful to frame tasks moving forward and next projects. Hopefully someone starting earlier than me will read this too.

    2. 1

      Everything I see from you is always so legit. Could see you lecture at a business school (though you probably love making more than teaching haha).

  2. 12

    Software engineers build things to meet a specification. That includes meeting quality control requirements, laws, regulations, standards, etc. Entrepreneurs and hackers are trying to figure out the speciation. They are trying to figure out what users needed. In that process they don't want to do anything but the bare minimum, because most of the time they are wrong.

    Consider the delete function. What are the odds an early user will want to delete an account? 1/1000? At that rate you'll need 100,000 users before manually deleting accounts becomes burdensome. Usually people will focus on getting their first 100 users.

    The other way to think about it whether the feature or functionality is critical to the idea you are testing. Will anyone sign up because there is a delete function? Is the purpose of the app to delete the account? Sounds silly, but this is the thought process you can apply to every feature or function to check if you need it.

    Hope this gives some idea.

    1. 2

      Thanks Artur! This is so obvious, but why I didn't see it- idk. Partially, I think I also was nervous that learning to implement delete or other features would be too hard to try to attempt after the app is live as a newbie- I thought if I made changes after it's live I might be too slow for users, break the app, or ruin user data. But I'm getting more confidence that I can figure things out as they come.

      1. 2

        It too me a long time and some failure to learn it. Once you put a product out there which you think is great, and nobody uses it, you'll realize that there are no points for perfection.

        It's a valid fear, but should not be a big concern early on. You can later research A/B testing and development servers. There are methods to avoid updates destroying your whole app/user base.

      2. 1

        My advice is to use tests and you will get much less pain with bugs when ship new feature

  3. 6

    One year, if well spent, is not too much. The question I have is regarding the path you are following. For what I understand, you are 100% focused on building and adding features. Have you talked to potential customers yet? What do they think of what you have up to now?

    You are in the double process of wanting to build and learning to build. That’s always risky unless you take it as a learning to code opportunity and not a business opportunity. Those skills will help you out in your future, no doubts.

    For the business side, there are plenty of opportunities to learn and perhaps the best is by finding a mentor. Someone who can ask ‘have you thought about this?’ At the right moments can go a long way.

    Regarding MVP, for example, you are the one who should have found out by now what your customers want. Regarding administrative features, that’s not for your users, it’s for you. Deleting an account can always be done by hand, purging the database, etc. Unless your business case is centered on the automation of the backend admin, you could better spend your time focusing on the things people may want.

    1. 1

      Thanks aqui. Yes, I talked to potential customers in the beginning, but have ben maybe too focused on building for the most part.

  4. 5

    Here's what I like to say to engineers-turned-founders:

    What is the riskiest part of your business? Is it really coding the project? Are you actually unsure that, given enough time and focus, you might fail to deliver the product?

    For most businesses, the answer is no. There are exceptions (building a complex AI is a great, common example), but usually, the truth is that the actual development is not what will make or break your success.

    What will make or break your business's success is whether or not you can reliably attract leads, and whether or not those leads reliably buy.

    In other words, most product ideas don't have Product Risk anywhere close to the degree that they have Channel Risk and Market Risk.

    My challenge to engineers is always this: Why are you delaying the riskiest part of your idea? Why are you going through all of this effort while the biggest killer is somewhere out there, in the shadows?

    Instead, I highly recommend going after the riskiest parts of the idea first. This isn't my idea - it's basically what books like The Lean Startup have been suggesting for ages. But people are only focused on the MVP concept from that book, and miss the bigger picture.

    For 99.9% of founders, the riskiest part of a business idea is whether or not people will actually pay money in exchange for your product. In my opinion, this means that it's worth aggressively chasing sales as early as possible, even if you only have a prototype to show to customers.

    Odds are, if you've really nailed the product/market fit and positioning, your early adopters will be so excited by the possibility of the product that they'll be asking to pay you right now for access to your early beta!

    Yes, it can be awkward to chase sales when you don't have a fully-established product. Yes, it's anxiety-inducing to really put your idea to the test in the market. And yes, you'll miss out on some customers who will only want to buy once they can get the software in their hands.

    But here's the million-dollar question: Would you rather run with a business idea that's so good that people are lining up to pay before the product reaches maturity, or would you rather have an idea that people are "meh" about until they get it in their hands?

    Personally, I find that chasing pre-sales and asking for payment as early as possible to be the best litmus test there is. It isn't foolproof, but it's the best test there is to explore the riskiest parts of a business - whether or not you can find leads, and whether or not you can convert those leads into customers.

    Obviously, this is a huge topic with a lot of nuances and I've generalized a ton, but hopefully, you can understand what I'm getting at! If I were you, having developed for a year without proving those two things true or false, I'd get the product to a ship-able state immediately and start figuring out how to sell the thing.

    1. 2

      Thanks Kev. So true. Accessing risks incorrectly can drive some bad decisions. Starting out I was unconfident about my software skills, so it accentuated the feeling that the software side was a risk. And maybe at that time, it was. But now I've learned more. So I feel more confident to perform a software task under pressure- like if a user needs something fixed asap. The only risk now is as you point out- will it work in the market? But it also feels like the security aspects might be a risk, similarly because I'm new and unconfident in my understanding of the risks. This is something that makes me more uncomfortable launching too early. And I'm not sure if it's an overly "software engineer-y" concern. I get a lot of software engineers telling me not to launch before making the app secure, but are they over estimating the risk because they are thinking like an engineer?

      1. 2

        Hey,

        Yea, security is always a tricky concern. There's a reason there are so many cybersecurity startups making crazy money. The web is an inherently insecure platform that we've been patching as best we can over time. The world-wide-web simply wasn't designed with security in mind.

        The reality of web security is that you aren't ever going to be fully protected from a knowledgable, intentional hacker. Not without hundreds of thousands or millions of dollars, at least. ​

        One way to think about how much effort to put into security, in my own unprofessional opinion, is like a line graph where the number of users is the x-axis, and the effort spent on security is the y-axis. On the graph, the line would grow completely linear, a straight line slowly going up and to the right.

        In other words, you can just worry about meeting the minimum bar when you have very few users (is all my traffic being encrypted through HTTPS? Is my database encrypted at rest and encrypted in transit?). As the company grows, so too should your security concerns.

        It's easy to become paralyzed by the security risk, but at some point, you have to say to yourself, "I've done my due diligence for now, and I'll keep revisiting this over time as the product grows."

        Starting out I was unconfident about my software skills, so it accentuated the feeling that the software side was a risk. And maybe at that time, it was. But now I've learned more.

        This definitely makes sense, and you're right that as a new programmer there is real risk in not being able to deliver the product. Only you can tell where the biggest risk lies since you know the most about your product and dev skills.

        My main point is really this:

        I see that you're very focused on the software side of the equation. The software side is important, obviously, and you don't want to expose any security vulnerabilities that make it trivial for someone to access your customer's credit cards, for example.

        But it's so easy to ignore the other aspects of the business that are equally important. It's very soul-crushing to spend a year in development only for the product to flop once it reaches the market (speaking from experience here!) and there are things you can do to minimize that risk.

        1. 1

          Thanks Kevin. I just posted a new q about security vs shipping faster. This is very insightful.( if you wanted to copy this answer into my new question it might be helpful to someone coming around it in the future). I think your general point is true. I definitely need to ship sooner than I suspect. But maybe it's still a good idea to consider how to implement minimal necessary security for my situation without getting carried away. I do wonder what the minimum security I should implement is.

          1. 1

            What's your tech stack? I'm no cybersecurity expert, but I'd be happy to offer my $0.02 as to what you should be looking for.

            1. 1

              Thanks! Node/express, react, mongodb, material UI(not sure if that matters?)

              1. 1

                Here are some resources you should take a look at!

                Express - Production Best Practices

                OWASP Top 10 security vulnerabilities

                As long as you're hosting your production database on something like Heroku, Render, AWS, etc., you should be fine with the database security. Just make sure that you never connect to your DB directly from the React app, the React app should call your Node backend and only your Node app should know how to call the DB.

    2. 1

      Holy shit, man. This is pure gold.

      1. 1

        Glad you found it valuable!

  5. 5

    Here's a tidbit more of guidance:

    1. Stick to a minimum viable product (MVP) first. This consists of just enough for users to use the tool and accomplish what they came there for. It doesn't have to perfect. It doesn't have to be pretty.
    2. Launch.
    3. Add in more features in order of usability. How many users would want to be able to delete their account (not many) vs how many users would want search functionality on a table (probably a lot).
    4. "Launch" again.
    5. Get user feedback. Answer support tickets. Make the system better.
    6. "Launch" again.
    7. Repeat steps 4-5 over and continue to increase profits!

    i.e. for instance with the delete button, you'd actually need users who stayed long enough to want their account deleted. So at worst this can be done a few weeks from now at the earliest. Figure out what tasks are low priority and which ones are high priority. New entrepreneurs always have a tendency to wait too long to launch. You are your biggest critic. I haven't even seen your site, but most likely people will think it's awesome even if you think it's flawed.

  6. 4

    Ok, you want to ship it faster, so ship it today! What is holding you back from shipping today?

    I know you you probably come up with a list what is holding you back, but remember that you don't have to fix everything.

    I'm a developer that learned this skill by working in small companies, seeing how they were able to survive and get revenue.

    1. There are problems that you 'want to have'. Bad scaling for example, is a problem that you want to have. I remember one of my colleagues who was going to do something manual for every customer we had. I said it's crazy because "Are you doing to do this 20 times a day?". He responded "That is a problem I would love to have. I hope I need to do 20 a day, because then we can automate it". So make sure you don't fix problems now that are not problems yet. Some problems you want to have, and all related to scaling is like that.
    2. Does it provide value to your customers? Deleting an account is not providing value to your customers. They don't care, so skip it.

    Just ship your stuff today. Early users will forgive a lot of things, as long as it solves their problem, they can put up with a lot of other broken things.

    1. 1

      Thanks for your reply. It just doesn't feel ready yet. Some stuff that doesn't feel ready maybe I can let go of- like frontend validations for usability. But it is hard to tell which features are ok to ignore. What level of broken is ok?

      Like is it ok to ship even without security features- ex backend validations? CSRF prevention? Maybe this is a case by case situation depending on the sensitivity of your users info. My users are very private about their real identity. I don't know if that's something I should worry about since the only information I have of theirs is their email and stripe account ID. And I'm not sure what hackers can even do with CRSF attacks- maybe they can't even get this data?

      If it crashes and loses important data is it ok to ship?

      How broken are we talking?

      1. 2

        Did a user ever use your product? You are worrying about usability, but your problems might be way bigger/different.

        For security, what is the worse that can happen? Seems like not really bad. You don't have users anyway, so there is nothing to leak. Like I said, a security issue exposing all of your 5000 customers is a problem you want to have.
        Worry about it when you have 100 paying customers.

        Daily backups can be good enough in case of data loss.

        Sometimes it's better to ask forgiveness than permission.

        You have 0 users now, it's time you start learning what they really want. I'll tell you, it's going to be different than what you thought.

        1. 1

          Thanks man for your perspective. I think daily backups would help alleviate some of my worry. This is inspiring me to ship it much sooner. Maybe a very small group of beta users will help ease me into it.

          1. 2

            Yeah, beta users would be a very good idea.

            Anyway, managing customer expectations is a very important thing. So if you bring it as a beta at first, your first users will know, and also give you feedback. That way you can concentrate on what they find important.

      2. 2

        I think i heard this from some YC videos (recommended watch on youtube),

        If you are proud of your app on launch, you launched it too late.

  7. 3

    I'm a software engineer too.

    Best way I've found to solve the "work on useless features" problem is to start actually needing the app to succeed. For that you need to take a risk like leave your job or invest your savings.

    I started my app almost three years ago, and released the beta about a year ago. We're now only approaching our public "official" launch.

    But it's just recently that I stopped over-engineering everything. Because now that savings are running out, it's becoming clear that my priority is to make money. And creating a way for people to delete an account doesn't help much.

    To give you an example, here's what my app still doesn't have:

    • order tracking, it's just a stripe checkout link and I create / send every invoice by hand
    • a way to delete your account (I just wrote "please write to us and we'll delete it for you")
    • a way to merge accounts created via email password with accounts created with social sign-in (google)
    • tests for most complex things

    And yet we're approaching our 100th sale.

    So yeah, my advice would be for you to maybe take a bit more risk, to force you out of your "engineering" comfort zone.

  8. 2

    What is the core value of what you are building? What job does it help your customer complete better? Now, which features contribute to helping the customer complete that job? Look into the Jobs To Be Done framework.

    If it doesn't contribute to a core JTBD, really ask yourself why you should focus on it, and if there are work-arounds. "Good enough" is what you are looking for. You can absorb the cost of workarounds and tech debt at first.

    The MOST IMPORTANT thing for an indie hacker I think is embracing tight feedback loops. If your core features work, you can test the value with customers and iterate, while everything else is duct tape and baling wire behind the scenes. You can solve most edge cases when it's time to scale up. What's most expensive is wasting a bunch of time on something without adequate course correction along the way.

  9. 2

    I have launched a product just today which I have built for past 3 months. I'm also a self-taught coder so I telling you how I coded it and my philosophy -

    • I don't intend to be a software engineer, I want to just launch a product. I have a buggy hacky app.

    • My app is made with react, Nextjs, firebase. No typescript and definitely no test cases.

    • And I didn't even know I had to give an option to "delete account".

    I don't even have a way to "change profile pic" if you use email and password to signup, I saved it for v2.

    Actually I thought of removing email/password signup just google signup(which is just few lines of code with firebase) no email, verification, password change, forgot password but few people have asked me in my previous launch why i have only google login so I caved.

    Don't do Design - I'm a freak about design I started with "human design principles by Apple" and custom UI with tailwindcss. It's a disaster, it takes so much time and is (very * 1000 times) hard than it looks and using a beautiful UI is not equivalent to building one. So I settled for simple one which is just what i'm capable of. (take a look below)

    My justification for all above is - would my first 10 or 100 customers really not use my product because they can't change their profile pic? or lines don't go parallel ? or don't have consistent paddings or borders ?

    I guess not and by the time those mattered I would have had lots of time to build, if it really needs fixing.

    btw if you want check my v1 app - https://aureliocbt.com

    P.S : V2 with "change profile pic" feature is coming soon 😁

    1. 1

      Thanks! I put a lot of work into the design, and am realizing maybe it wasn't necessary. My potential users did say they wanted the ability to post big pretty pictures. So it seemed that beauty was important for my audience. But I think where I went wrong was making every page pretty- the email confirmation page for example has a cute little graphic I made in AI of a cartoon envelope and confetti. Very pretty, but I think my users would have forgave me if it wasn't there haha. I'm thinking they really just wanted their profile page and posts to be pretty! Sometimes one user/potential user will say something and I will run with it perhaps too far.

      1. 2

        AI of a cartoon envelope and confetti

        🤣 I too am guilty of this. In my fear ladder feature, when all steps are completed, a confetti blast animation happens and smooth opening of dropdowns. I know all animations are aesthetics but it does feel good to see your app do cool stuff.

        But a good rule of thumb is not to speculate a time consuming feature.

        I built all features which were either necessary (functional) and some easy ones which I felt really good building 😉.

        My next features would be after i see the usage analytics and feedback from my users. Till then I'm going to sit tight and do marketing.

  10. 2

    Dont freak out, I have worked on projects that took three years to build (and that then tanked). I see a lot of things built here that take three months and guess what? When I look at them they look like they have three months of effort in terms of functionality and features. People are trying to find that golden thread to pull and get validation first followed by continuing building. Not everything is so simple that it can be built in three months, especially by one person. Especially if you are learning as you go. It's clearly a learning process but everyone expects to smack a home run straight out of the box.

    You point out that you didn't know you could cut some corners but really it's about prioritizing the core features and finding ways to deal with the rest based on that priority. You are trying to build to absolute completion, which actually many people still do, not everyone is 100% bought into the MVP approach. That approach is about saving time but it almost never results in a great product on day one.

    You might be far enough along where you are now if the basics are working, ask yourself if you would show what you have now to someone and let them play with it? If it does the basics you might be almost ready to go, if not then hey it's just taking a long time because it's your first build and maybe it does more.

    1. 1

      thanks, Definitely good to remember the context of my situation might be different than others.

      My product is almost something usable- but there are a few bugs that I feel will confuse users- like when they make a change the page doesn't update to reflect that change or show nay sign that the change was successful unless they refresh the page so it looks like nothing happened. I also wanted to add more frontend validations for usability but maybe this is unnecessary. However, I feel I still need to add backend validations for security purposes. My assumption is that no one would ever skip security like backend validation and CSRF prevention- but is that assumption off-base too? I know little about security so I'm not sure what I don't know.

      Maybe it depends on the sensitivity of information on the app? My potential users are a bit protective of there identities, however the only possibly sensitive info I have of theirs would be their email address and the account id of their stripe account- I'm not sure what someone could even do with that.

      1. 1

        You have some very specific developer questions that may be better suited for a different forum like a Reddit dev group or Github or something - I'm not a dev. You may well be closer than you think though like suddenly after a number of tweaks you will be looking at it and realize "hey it works". When it does you can start your second job - turning a piece of software into a well-explained service offering with a website and also turning it into a business. After that, it's a loop of sales, marketing, and product tweaks.

  11. 2

    read this book today! The Lean Startup by Eric Ries

    1. 1

      Thanks, I actually just started listening it this morning after someone else suggested it in response to this question too.

  12. 2

    Not sure the backgrounds of the other posters, but I was like you - I do not have a proper SW engineering background and was teaching myself how to code + building my product full time, days and weekends. I do not know what your product is and how fast you are learning and what your stack is, but I think a year is too long if you don't yet have this in the hands of any users / beta customers. I understand the legal requirements and fear surrounding GDPR, etc. but a) the chances of you getting caught are incredibly slim and b) do you have actual customer accounts yet?

    One example is billing - for the first handful of customers just manually send a Stripe invoice / activate and cancel their subscription using the Stripe web interface. Once more customers are signing up, you can worry about integrating the Stripe API and building your own billing portal.

    You should be interacting directly with your first customers anyway, as it builds the relationship and also allows them to give you feedback which is critical. If you haven't yet put this in the hands of a single user yet, I almost guarantee the product you have in mind is not the product they actually want and you will need to make modifications / pivots to get it there - this is frustrating, but this is how useful products are built. The faster you can close this feedback loop, the better.

    The last thing I find kind of odd is that, as someone who doesn't have an actual software engineering background, you are indexing more heavily on spending MORE time vs. LESS. You have the luxury of not knowing what you don't know (I still don't know what I don't know), and because of that you should just be focused on getting the useful solution in the hands of your user as fast as possible and other requirements will naturally arise on their own.

  13. 2

    Same situation here, don't despair! 💪🏻

  14. 2

    I can 200% relate to this. But working in a 500k MRR start-up that didn't have delete account, unsubscribe for payment, change your email, notifications, and so many features that felt necessary taught me you don't need much to get started.
    Your only goal is to get that first dollar, then listen to what that one customer asks for, and build it. You'll be VERY surprised to see what he asks for, and what he didn't care about.

    After being asked to do something, whether by a user, or by the lawmakers (that happens), you'll always have a grace period during which you can build, so don't worry about it, they'll understand (but deliver).

    Good luck NOT building all those features, it'll feel weird, but as the saying goes, you should be ashamed of your first product.

  15. 2

    A story I hope you already read this in IH but let me tell you again though I am not the best in this too. A guy just make tinder for movies where to decide which movies he should see along with his friend he launched the app getting thousands of downloads and 3 investor approaches him.

    What I want to says is a years back I learn how to build an app like tinder with flutter I still have a code I build something similar to his product but never launched it asume who use this why I have to spend 125$ for stores
    Long story short if you have an idean just launched it with bare minimum features

    1. 1

      I know him from Twitter and he lives in my town and we are going to meet this summer :) Some of his posts were the impetus for this post. Thank you.

      1. 2

        Whoo that's gonna be amazing well I think you work on wishlist platform I suppose

  16. 2

    Hi, as someone in the same boat (Have also taken a long time without officially launching), I can say that it was extremely helpful sitting down with someone so that they can use the site/app while you watch. Don't direct them, but rather let them tell you when they are confused or what they expect where and so on. You'll also be there to answer questions like "Where do I find X?", and then you know that X was expected/needed.

    Naturally I am not saying that you should change everything that they point out, but it helps to see everything through the eyes of the user. Or at least has helped me to prioritise a bit more.

    (And yes, I have a button for the user to delete their account. It wasn't a lot of effort since I anyway built in the functionality so that I could clear the demo account when needed so figured why not)

    1. 1

      Thanks, interesting idea

  17. 2

    Don't get demotivated by the noise of shipping fast, as you are self taught developer sometimes it may take time. We started a tiny application in April and yet to finish, beta launch is planned on August. That means 4 months with 3 people. My cofounder usually do everything with little more time, I'm perfectly okay with this.

    Good stuff takes time. Shipping fast may work for someone and it may not be ideal for everyone. I will never ship a half baked product or an ugly product, sometimes we will ship product with minimum features yet it should be lovable.
    If you are okay with finance (You got enough money for living without the revenue ) taking some extra time will not harm.
    As Allen pointed, try to minimize the features. Have 3 kind of features

    1. Must Have features
    2. Okay to Have
    3. Wow Factors

    Hope this helps, remember this: something worked for me may not work for you, so ask advise from different people and get the best out of them.

    Regarding your delete feature: If I was in your position, i may go for manually delete users initially. And when you are no longer able to do it manually start automating it.

    1. 1

      Thanks for this. It's good to remember too, as you said, that not every mantra works for everyone. But to take some pointers and apply them to your unique situation.

  18. 2

    Let me tell you how I did that-

    The problem I was facing was instead of developing product on my own, I want to hire freelancers and build the product. In all this, I wasted 3-4 months and end up getting nothing (some UI screen + backend).

    So I went back to the drawing-room, keep a paper and pencil and write down all the features. For the whole week, I had dropped all the unnecessary feature and also cut down the current flow.

    After a week, I have a bare minimum feature list, that was the core of the app.

    Now come to the development of the feature, I have use no-code tools and built the complete app in one month.

    Currently, I am only focusing on the marketing of the app, with no new feature nothing. Even some customer asked me, add that, add this. I have just written down all the requested feature and will only add when 70% of the existing customer will demand.

    #happy_product_building

    1. 1

      Thanks. I also considered no-code, but I already had some coding skills. No-code still interests me. But I also don't regret learning to build software. I'm also using my coding skills to build other cool projects like a brain computer interface. And yes- as you mentioned- one of my mistakes was taking what one potential user said and running too far with it! I should wait until more people give similar feedback.

      1. 1

        Great. I too know code but at times we have to make the choice of what we prefer and what method can save time and let's focus on the product.

        All the very best.

  19. 2

    It was mentioned already, but build SMALL. I'm not sure what the problem really is that had you 1 year I'm with engineers [hired?] involved but still stressing launches if you are the owner. But the worst mistake any person can make is being able to hit the brakes and discuss a potential re-write due to believing scrapping requirements is ultimate failure. (The ultimate failure being maintaining the same conditions regardless of so many red flags and never finishing or someone else beating you to market.).

    Consider building in public if you can, and post general details on your history of progress until now. If you cannot see the problems it may be you are too close to it, where as the community can encourage you to focus on anything that may be hurting your completion. If community is not possible then maybe DM a couple people and request a 2nd set of eyes....

    1. 1

      Thanks. I am building in public on here https://github.com/DashBarkHuss/100-days-of-code/blob/master/post-log-2021.md (haven't posted in a bit thought) and on twitter. I also have my project open on github. It's been helpful to build in public, but actually I this is my first post on indie hackers and it's I'm getting more helpful answers than I normally get on twitter.

      "But the worst mistake any person can make is being able to hit the brakes and discuss a potential re-write due to believing scrapping requirements is ultimate failure." Could you clarify this sentence? I'm a little lost (maybe I'm having a brain fart) about what you're saying.

  20. 2

    I think having a mentor or accountability buddy helps! Try it out!

  21. 1

    It took me more than 1 year to launch my first thing. Now, I give myself about 1 month to roll out MVP. You can skip a surprising number of things.

    Look at your funnel and scratch everything not essential for that.

    I guess people visit → sign-up → go through onboarding → get value → upgrade/pay?

    Anything not needed to complete these steps you can probably skip for the MVP.

    It's possible to be even more strict, eg. only implement payments when there is someone ending trial period / only add the "subscription renewed" endpoint after someone actually creates a subscription etc.

  22. 1

    You're way overbuilding.

    Get something quick and dirty into hands of users ASAP.

    You're racing against the clock here.

  23. 1

    I'm about 6 months into development on my product, with proabbly 4-6 remaining before I'll be able to launch. Why? My scope is inherently large for a solo developer building their own business from scratch for the first time. It could be a mistake to take on such a large scope, but I have a partially validated idea for a target industry and the domain knowledge to execute on it. It can be worth the time investment, and plus as an added bonus, you learn a lot along the way. Few people take that chance, own it.

    That said, learning to do the minimum required is challenging. You have to be ruthless and be okay with "good enough", so long as the core saleable features make the cut.

    For example, I'm leaving features like "filter results / search by text" for a release after I launch. Not because they aren't important, but because they don't directly correlate to my value proposition and do not block my from trying to make a sale.

  24. 1

    Agree with the opinion about the mentor!
    I had a pleasure reading about your journey!

    Wish you only luck with your app

  25. -1

    This comment has been voted down. Click to show.

  26. 2

    This comment was deleted a year ago.

  27. 2

    This comment was deleted 3 years ago.

    1. 1

      Thanks! What do you mean by "Use third parties"? Do you mean work with other people or are you talking about tools?

      1. 1

        This comment was deleted 3 years ago.

Trending on Indie Hackers
Yayy! Made my 2nd sale in one month 43 comments Help me positioning my SaaS product 23 comments Need feedback about the landing page 22 comments 🤯Blown Away, Everyday. 20 comments Productized service: Got my 1st client (€2500/m) with 100% upfront payment 17 comments Need Feedback About My Landing Page 14 comments