
Stop Perfecting, Start Shipping - eekay
https://medium.com/shipharder/makers-stop-perfecting-start-shipping-3c1448e6920b
======
spectramax
I am not so sure. This is a handwavy advise I always hear from contemporary
business wizbangs, but I don't think it is objectively or universally true.
Pedantic, careful and attention to detail, perfectionist products that _just
work_ without things breaking all the time are a pleasure to use from the
standpoint of the customer. Figure out the implementation details, funding,
motivation, etc. as an entrepreneur - shipping broken products to paying
customers is something that I only see in the software industry. You don't buy
a vacuum cleaner and expect to send half of the missing screws to the customer
6 months later. Hell, just 20 years ago when you bought your SEGA game
cassette, it shipped as a final product. Not to be patched ever. Once its out
to the factory, if you found a bug, tough luck. Yes, this analogy has its
limits, but silicon valley mentality of this startup hustle is questionable.

I recommend watching this incredible talk (it's about software) :
[https://www.youtube.com/watch?v=pW-
SOdj4Kkk](https://www.youtube.com/watch?v=pW-SOdj4Kkk)

~~~
eekay
Physical stuff != code...

It isn't about having functionality served half-baked but about having
minimalistic functionality (only serve what brings the most value for the
users to their table) and go from there.

It is irrational to think that you know _exactly_ what people want/is going to
provide them with enough value to keep coming back to your service/product...

So why not start small by building the basics, releasing them, getting
feedback and use that to move your product in sync with what the users
want/need.

I loved the sega games as much as the next person, and I truly admire how they
got so much shipped with such limitations.

But this indicates one big problem of makers nowadays: building functionality
has become easier and easier with all the frameworks/tools/no-coding/... stuff
that it has become too easy to ship too much (or lose yourself in keeping
working on adding just a little feature here and there), thus straying away
from shipping and getting that _golden feedback_ from actual (paying) users.

I'll be checking out the video later, thanks for sharing and your feedback!

~~~
spectramax
> Physical stuff != code...

Think more abstractly. A business is delivering piece of IP to the customer in
exchange for monetary value. The _medium_ of this IP can be physical or
intangible. It is the delivery latency that's different. If those screws that
I talked about arrived in about 45ms latency from the warehouse to the
customer, and fitted themselves in another 2mins, you could patch things
instantly. Just because this latency is different, doesn't mean you ship MVPs,
broken pieces of software that require constant patching. Take time, carefully
think about the architecture of the software, think about extensibility and
modularity. Avoid feature creep, instead work on _just works_ aspect of the
product. This is why I love software from companies like Sublime HQ. They make
fast, efficient, well architected software that's a pleasure to use.
Similarly, there is something beautiful about unix utilities, little pieces of
software that just work :) Continuous delivery is great for huge software,
Arch Linux, for example.

~~~
eekay
I totally agree that setting up a product that is extensible, stable,
scalable, etc. is something that needs to be done.

As I see it, and how I'm currently executing, is that the focus on
extensibility and modularity increases over time. I look at making that
extensible software as something that starts in an MVP with a focus on 1K
users max, and grows and becomes more important from that point on. So it is
something you can do a while after the initial launch.

> Just because this latency is different, doesn't mean you ship MVPs, broken
> pieces of software that require constant patching.

I agree that the MVP should be working properly. No doubt there. But it should
also focus on testing if it provides value (and see if it actually is
viable?). By capping it at 1K users to start with you can focus on the value
part instead of spending your time on tech implementation at first.

Especially for bootstrapping solo founders, I strongly believe that the focus
should be on the value of the product in the beginning, not in the setup of
the technical solution.

I'm going to use my own case as an example:

As a single developer I'm working on a product idea (sharing your videos via
enhanced QR codes that enable Augmented video watching without the viewer
having to install an app).

I could set up the infra, cloud services, build extensible pretty code and do
the works in getting this ready to shine and go for 10K users.

But I chose not to. Right now, I'm focussing on the proof of concept (which is
for showing ME that the idea is feasible and usable in the ways that I want it
to work).

The PoC will only have the concept of working roughly and the code will be a
lot of hacked-together code that makes sense to me. This isn't an MVP as I
won't have user accounts, authentication, security, payments, .. implemented.
Just the core functionality.

I'm going to share the product with a bunch of people in my network to get
initial feedback about it and I'm going to use it myself.

I probably will use footage of using it, along with an explanation of the idea
for a landing page.

I'll know within a week or two if the idea is good enough to keep using it
myself and I'll have my network feedback along with things I didn't consider
that need to be in check.

When the lights are green, I'll start a new solution with clean code and the
core functionality from the PoC implemented so its clean, expandable,
maintainable, secure, tested, etc.

I'll have the minimum feature set around it (security, accounts, support
channel, payments, ...) to make it a whole experience.

For the MVP my focus lies on reaching 10, 100, and then hopefully 1K users.
And I will have a tonne of work laying ahead of fixing stuff, giving support
and helping out.

I'll also have metrics about bandwidth usage, unforeseen scenarios, people who
are working my product and stretching its limits in ways I didn't even
consider.

And _that right there_, that moment after I hopefully have a bunch of users,
is where I would make sure the amount of users is capped, and where I start to
invest time on making this more scalable, improving the app experience, see If
there need to be changes of the services used I'll use in the background
(behind the API), etc.

There will be a lot I've learned by this point. And if the product has proven
to be viable (I gain enough revenue from it to justify working on it), I'll be
working hard to make it even more secure, stable, scalable, and future proof.

While writing this, I feel like we aren't that different in how we look at
things. Perhaps its semantics, perhaps I just need an extra cup of coffee.

I think that the focus on CI/CD, scalability, modularity starts with the MVP
and increases from there.

I know there are quite some products that ran a nice MVP and reworked their
backend from scratch on after some time to make things more flexible and
elastic to take on more users.

My mantra:

Code Hard, Ship Harder

