Live data from Hacker News

How to start and scale a full stack startup

blog.42floors.com

11–20 of 28 posts

Re: How to start and scale a full stack startup

#11
I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code.

I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have started building the tool, just that you went way too damn far once the "bugs" and "feature requests" came rolling in.

What about the relative costs and risks associated with hiring a workforce for all the manual labor? There's a certain net weight in work that needs to be done, you can shovel it by hand or you can build a machine to help you. How is it not a winning move to hire fewer, smarter people, and empower them with a great software stack?

The goal isn't to build a machine which can do 100% of the work. But whatever the product you sell, you may find you can spend $1 in engineering to reduce the variable cost of delivering that product by more than $1. That's printing money. But to identify these opportunities, and more importantly to prioritize these opportunities and stop working on the BS never-pay-you-back feature, I think you need a project manager who can understand software complexity as well as the business case.

Re: How to start and scale a full stack startup

#14
I think the author is learning the wrong thing.

Software isn't about automating things, and certainly not about automating things 100%. It's about building tools to leverage people's times (in this context).

If you can build software that makes those folks doing those manual processes 30% more productive, then do so.

He has this idea that you should never build tools by default because automating them 100% is too costly. Automating them 100% may be too costly, stop trying to do that.

Re: How to start and scale a full stack startup

#15

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

The whole overloading of "full stack" really bugs me. I lean towards definition (3) above. Software can run front end to back (or some portion there of), but most "full stack developer" gigs kinda stop at above the hardware level.

For me, knowing the right choice of software components best suited to the platform (vms, direct hardware, etc) and how to tweak the platform is as critical as any other layer above it.

Re: How to start and scale a full stack startup

#16
post #11

I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code. I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have sta…

A lot of times you are going into existing, older markets where there isn't just a "set of requirements" to be defined by a good PM. Commercial real estate is a great example. The existing processes in renting are extremely case-by-case and specific. You need to go in and first define how you will start to standardize things, and get buy-in from the industry around that process. So you start with the manual, and then automate as you find fit.

This is different from creating enterprise software as a vendor. When you go to one large corporate and they want software automation added around their process, they usually have a process to be standardized. So then you can just figure out and write up the requirements. When you are building a more generalized, SaaS-type product for an industry as a whole, no one yet even has a vague idea of what the process and requirements are.

Re: How to start and scale a full stack startup

#17
post #4
post #3

> Start with manual processes This actually goes for all companies. Early on, whenever you can replace code with a manual process, you should; if for no other reason than it can help you to iterate faster. We do it religiously at 42Floors. Everything starts manually. Save your precious engineering cycles for the times when you actually need it. God, there needs to be a sexy phrasing of this, kind of like how quick-it…

I realized exactly this when I wanted to write a backup script for some of my client's websites. My usual process had been to 'manually' backup using rsync, which was a matter of cutting and pasting the commands from a text document. When automating, however, I realized I'd also have to check if certain files (db dumps) were present, and of course if the script itself succeeded. I then realized that in this particula…

Automating is not just about speeding up the process; it's also a way of lowering the bus factor[1] of the process. What happens when you go on vacations, or you get sick? Do the websites stop being backed up?

Besides, you should always document your process, and writing a backup script doesn't really take much more time than a detailed description in English.

[1] https://en.wikipedia.org/wiki/Bus_factor

Re: How to start and scale a full stack startup

#18

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

"full stack" == "jack of all trades"

Re: How to start and scale a full stack startup

#19

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

I'm just waiting for the Full Stack Cloud to become a thing

Surely that would disrupt the industry. Social, mobile, local!

Re: How to start and scale a full stack startup

#20

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

I always thought it was meant to indicate proficiency with all 7 layers of the OSI stack.

So if you can't design and build a network (2 or 3 buildings 2-3k hosts) you are not a full stack developer.

Btw this small network is what CISCO expects a CCNA to be able to do.

Post reply on HN