May 26, 2019

Launching troubles

Kyle Samera @ksamera

Does anyone ever fear launching because you know the product could be better (e.g. implementing new features or making performance better)?

As a follow up, is there anything that helps you to get over this mental hump?

  1. 1

    One of my fears is based on the concern that I can change the format of some database entities in the near future and users using the old format will not able to work with them anymore. Providing the back compatibility is not the highest priority (especially on the time of MVP) so it creates a real stumbling block.

    How do you think I would overcome it?

    1. 1

      This is what database migrations (and backups) are for, coupled with an approval or QA build/environment.

      1. 1

        I use database migration but it just helps to cope database-level troubles but not app-level ones.

        1. 1

          It depends what it is you are shipping. I'm shipping a web app, and the migrations ship with each new release, the website simply goes in to maintenance mode whilst they run, the new code is put in place, and done.

          If you're talking about something like exposing a public API, and you wanted to change a REST call or something, then you'd use API versioning.

          1. 1

            What tools/libs do you use for migrations?

            I use alembic for SQLAlchemy (Postgresql) and it's very limited. I'm not able to specify that this specific field has been renamed or so.

            I ship web app too.

            1. 1

              I use Laravel so migrations are a breeze!

    2. 1

      You can circumvent this by wrapping your database schema in domain models. That way, though the underlying schema may change, you can still provide a single interface to your users.

      If you're using an ORM then you're already doing this to an extent. You version your APIs. You maintain api/v1 for however long (while converting users over to v2), you change the underlying structure and provide /v2. If you've abstracted access to your database schema then you may even be able to change it without affecting any consumers.

      How are your users accessing the data?

      1. 1

        Thanks.

        I thought about using different versions of API. But it's too much for now. I could even develop the main product (it's big and complicated) and my goal is to launch asap. Versioning API would be an additional hassle here. I would prefer some "seamless" approach but I don't know if it even exists (I suspect that doesn't).

        Yes, I use ORM (SQLAlchemy for Postgresql). I have several layers (from user direction to data):

        1. UI

        2. API

        3. Model domain

        1. 1

          Do you have an example of one of the schema changes you are struggling with?

          My thought is could you not make those changes while providing the same API to users? Internally, you could even use a common interface between UI/API (repository, for eg) and have that hide any schema details, too. That way you can change the schema without affecting UI/API.

          Of course, this depends on the actual changes. Might be even simpler if the UI consumes the same API users do.

          1. 1

            Do you have an example of one of the schema changes you are struggling with?

            The simplest case is when I refactor and rename fields. So, if I rename account to account_id (because it's actually account ID) first of all, account column will just disappear from the database and users will lose this information.

            Of course, I can provide some code like "if your account field is null, go and find account id by user id and put to account_id" but it will make the code dirty and probably more buggish.

            I would prefer to find some universal solution.

            My thought is could you not make those changes while providing the same API to users? Internally, you could even use a common interface between UI/API (repository, for eg) and have that hide any schema details, too. That way you can change the schema without affecting UI/API.

            Not sure what you mean.

            1. 1

              An example of abstracting away that change would be providing your users with an endpoint to access their account, where you can choose what to put in the response.

              For example, to them it may still look like 'account', whereas underneath you are now using 'account_id' from the schema.. unless I'm missing what you mean? Do you mean renaming fields in an API response along with schema changes in the db?

              If so, the only solution is to either continue to fill legacy fields or create a v2/v3/etc endpoint with the modified structure.

    3. 1

      Definitely a road block there. I’m not really heavy on backend dev but maybe another indie hacker could chime in and offer some help here?

      My projects don’t specifically need much more data than contact info but I could see that being an issue in most projects.

      1. 1

        Thanks for your response. Yeah, I wonder how other ih-s solve this problem :-0

        1. 1

          I'm still building my product but on a high-level you should define the bare-minimum amount of schema information to maintain in such a way that features and functionality are not inhibited. And moving forward you are free to add columns but not remove any, especially not ones that may contain user data or are serving a substantial part of functionality.

          1. 1

            Thanks for the piece of advice.

            But if don't remove any columns the whole table will eventually turn to be a real trash can. On the other hand, maybe at that moment, I would create a mechanism to provide back compatibility.

    4. 0

      Use different entities/domain classes for your public API and your data base structure. The idea is to keep the public facing API as stable as possible and keep flexible under the hood. If you change the DB structure you "just" migrate the data to match the new schema. API can stay the same as before.

      Second, think about a versioning strategy. Mainly, how will you be handling breaking changes in your API. This justifies a new version but maybe you do not need it when no users are involved in changing anythin on their side.

      If your UI is the sole client of your API, I would not worry much about this as you can change and deploy all parts at the same time.

      1. 1

        Use different entities/domain classes for your public API and your data base structure.

        I'm not sure what you meant. I usually don't change API itself. But data and data structure may be changed what can cause loss of data, exceptions and errors.

  2. 1

    What helps me is understanding two concepts that might be counterintuitive...

    First is that realistically, success won't come overnight and there won't be a mass influx of signups directly after launch. The product you put out will be seen by some, but it takes a lot longer than you expect to get traction or press or anything like that. I used to fear that if some part wasn't complete or fleshed out, a potential life-long customer would churn and never come back. Basically, that's just not a realistic situation haha.

    Secondly, getting the product out into the world, even if it's not complete/perfect, always sparks small (or large) shifts in the product or approach. These shifts are critical to success, and no business has ever succeeded without customer feedback. Why wait to find that out later? The best thing for the product is to test it in the real world and know exactly what areas need to be adjusted.

    Plus, of course, you'll never be done building and improving, so it might as well be live and growing while you do it!

    1. 2

      These are great insights. The customer feedback part is definitely a good motivator. It just makes sense. Thank you!

    2. 1

      I used to fear that if some part wasn't complete or fleshed out, a potential life-long customer would churn and never come back. Basically, that's just not a realistic situation haha.

      The moment of the truth!

  3. 1

    Yes, 100%. I just soft-launched an MVP and I have a ton of things still on my todo list. The 2 biggest mental hurdles to get over were: 1. Having enough content on the site to make it useful without spending a lot of time on that before proving product market fit; and 2. Not having all the marketing built out that I want to do. I have landing page ideas for multiple personas that should help onboard those specific types but again I don’t want to invest a ton of time until I can tell if anyone else but me finds this useful.

    My strategy at the moment is to soft-launch and put it out to a few groups and try to get feedback on usefulness and what’s confusing and make a decision whether to proceed based on that. I can’t tell you yet if that’s a good strategy but that’s my approach to this problem so far. Good luck!

    My MVP is https://slpstream.com/

    1. 1

      Just some feedback on the naming. In the domain you write slipstream without the I but on the site the name is always with I. When I enter "slipstream.com" because i only remembered the name, I end up on blackberry.com. Aware of that?

      1. 1

        Hi Azarai, Thanks for your feedback. It is a concern. I couldn't get the .com for Slipstream and .net and other memorable extensions were taken. I had other names on my list but liked this the best. I am on the fence about switching to another name or trying for a different domain. It helps to get your feedback on remembering the name but not getting to the right url easily. I might start a new post on this topic and see what the community thinks. Thank you.

    2. 1

      I think soft launching is definitely a good idea! Thank you for sharing your experience. It’s really helpful.

      I also like the idea for your site slpstream.com:)

  4. 1

    I agree with @trike. It will never be perfect, you'll just have to adapt to the situation and update it on the go. Take a deep breath & Keep Going!

    1. 2

      Thank you I will!

  5. 1

    It will never be perfect. You're making features for people you dont have yet and don't know really what they want. You're better launching basic functionality and building new features as they are needed by your users. Take them along for the ride.

    1. 2

      Very true, it’s sometimes hard to envision yourself on the customer side of the table to actually realize they don’t need X, Y, and Z right away.