7 ms·

How to run a startup in 2016: * No homebrewed tech allowed. It's too "complex" * We should only use off-the-shelf libraries and SDKs because bar-to-entry isn

How to run a startup in 2016: * No homebrewed tech allowed. It's too "complex" * We should only use off-the-shelf libraries and SDKs because bar-to-entry isn't a real investor risk ("Just trust me, I'm a charismatic CEO who played golf a few times with the best friend of the college roommate of the guy who helped the guy close Series A for Baidu") * Soft skills, soft skills, soft skills! Smiling > coding * I don't know what technical debt is, but I'm sure we can safely rewrite our core product from scratch in between Series B and Series C. Product owners, customer support teams, and quality assurance re-on-boarding is a money problem, not a leadership problem. * Security audits? I have no idea what those are, but lets incorporate IoT into our product suite somehow. That seems hot right now to VCs. Bubbles. Bubbles everywhere.

JoeAltmaier 10y ago
Re: No homebrewed tech Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not smart enough to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.
- ben_jones 10y ago
  "Can that corner be cut?" "Well technically yes, but..." "Good, cut it" .. 2 years later .. "How could we possibly have been hacked! We had security right?!" .. points behind at ten miles of cut corners ..
  - moron4hire 10y ago
    The problem was that the corner could not actually be cut. If the answer is, "yes, but we won't hit our performance targets," then the answer should have been "no, we won't hit our performance targets." Your management can't help it that you said it was possible.
    - 12931831 10y ago
      You should look up what "technically" means in that context.
    - JoeAltmaier 10y ago
      In my case, every meeting I had consisted of me saying "We need to know which features and performance goals we can sacrifice." Never got any answer. They wanted it all; they didn't want to pay for it.
      - lj3 10y ago
        Is it possible this was a communication failure not a technical one? I'm guessing your bosses couldn't tell the difference between the old performance level of your code and the new performance level of the off the shelf code. But, I'm betting they could tell the difference in communication styles. I'm guessing you said 'no' a lot and your replacements said 'yes' a lot?
        jazzyk 10y ago
        >"They wanted it all; they didn't want to pay for it." The above happened on almost every project I have worked for over the years. Q: "Can we take feature x out of the plan?" A: "We can't release the product/project without it" Q: "Can we then add 2 more months to the release?" A: "Absolutely impossible, the client will not accept it" You are correct, the reason is severe (and systemic) lack of communication: Product-roadmap planning either does not involve technical personnel at all, or at least not until the very last minute, when you are brought in to essentially rubber-stamp the plan. Saying "no" takes a lot of courage at this stage, you are seen as incapable/negative. The underlying problem here is that we are seen as mere technicians/workers, not planners or strategists (we are partially to be blamed for this, but that's a separate topic).
        jnbiche 10y ago
        I've also had exchanges very similar to the above. What I think happens is that managers think that we're negotiating. Negotiating for what? I have no idea, but for many managers, it's their default assumption. In fact, we're not negotiating. We're describing the situation to the best of our understanding. Indeed, when often these situations have started to feel like negotiations, I've stopped and emphasized that this is not a negotiation, this is my very best estimate as to what I need to get the job done, nothing more, nothing less. Sometimes this gets through to them.
- onion2k 10y ago
  Developers should definitely write their own code when there isn't an open solution that they can leverage to solve the problem, but those situations are quite uncommon for the majority of startups. Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design[1]. Building a business around that is much, much easier and cheaper if you write less of your own code. Use open solutions where you can, and don't use them where you can't. [1] That is in no way denigrating startups that do that. If you can solve people's problems by making a better form then that is a Good Thing.
  - exolymph 10y ago
    The way I like to put this — or a related concept, at least — is that no business should waste time building the aspect of its product that isn't the differentiator.
  - nostrademons 10y ago
    > Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design They should probably ask themselves what sort of defensible competitive advantage they're building, though. With many founders I know, the answer is "none". This is probably necessary in the very early seed stage - it's hard to build something unique and difficult and still get to market - but it's disturbing how many companies end up with $50M in funding and the answer is still "none". Probably a good indicator of a shake-out in the SaaS world in the near future.
    - Hydraulix989 10y ago
      Network effects are a good example of something that is both non-technical and defensible. You can't build the next Facebook anymore because everybody's friends are already on Facebook.
    - onion2k 10y ago
      The competitive advantage those companies have is typically two-fold: knowledge and brand. Knowledge is the very detailed and insightful understanding of what their industry needs at the moment, and where it needs to move to in the longer term. Founders who build those businesses are typically experienced in their industry and are solving a pain they've seen firsthand. That is exceptionally hard to compete with if they're good. Just because that knowledge can be codified in a 'simple' CRUD app doesn't make it any less valuable. The brand advantage is comes from being the first mover. If the industry knows your company, trusts that you've proven to have an impact on their bottom line (or their competitors bottom line), then you're probably in a good position to retain customers and build a market. Competition is not a problem for a business that's intent on making a market $100m bigger rather than trying to take $100m of business from someone else. Neither of those advantages require any code.
- chrismarlow9 10y ago
  The real kicker here is development at scale. Anyone that comes in has to learn how all that custom code works, and chances are if you're like any startup I've interviewed/worked at (20+), you don't have any documentation on the code, or it's so out of date it's useless. Meanwhile if you use that "off the shelf" thing and introduce a few hacks to make it work for your use cases, all I have to learn is those hacks and why they're there. The rest is already documented and maintained by another company who built this dev tool.
  - wtetzner 10y ago
    > The rest is already documented and maintained by another company who built this dev tool. Or more likely it is someone's open source project on GitHub, and is just as poorly documented as something in-house would be.
    - chrismarlow9 10y ago
      This is something that should be taken care of when vetting the project on whether or not the company should use it. Anyone whos been around that block a few times knows to look for: - current dev status (hasnt been updated in 6 months? probably shouldnt touch it) - community review (is anyone else using it, hows it working for them?) - limitations (this one is pretty obvious, technical limitations/benchmarks/etc) - code quality (unless its a third party service you pay for you should be able to see if the code is worth a crap pretty easily). - vendor lock (if we need to change, how easily can we change? do they use open source protocols/standards that other tools understand?)
      - wtetzner 10y ago
        But this is the point. There is no good rule for when you should use a library, and when you should build your own stuff in-house. It always depends on the specifics of your situation. You need to think about things like the quality of existing third-party solutions, and how well they will fit into your codebase. You might find a third-party library that is 90% of what you need, but there just isn't a good way to get to the other 10%, and so sometimes even in those cases it makes sense to roll your own. Other times I see people rolling their own versions of stuff, and it's clearly much worse than readily available libraries. You just have to look at the specific situation to determine the right thing to do.
- ktRolster 10y ago
  It's worth remembering that their is also cost involved in using someone else's code. Use it when the benefits outweigh the costs.
deleted 10y ago
[deleted]
ryanlm 10y ago
That sounds like this one guy who is trying to get me to work for free for his "company". "What kind of cyber security does your server have?" Speaking to me in buzz words is a huge red flag.
- crpatino 10y ago
  It is a perfectly good question to ask for the VC-type about to write a check to the one-guy you mentioned. The fact that you do not speak their dialect does not make their communication any less meaningful. If anything, it means you will always be working for some one-guy or another, instead of being the one-guy.
  - ryanlm 10y ago
    I understood his communication. He isn't a VC. If a VC asked me that I would know how to make an appropriate response. I'm also not fully aware of what you mean here.
dperfect 10y ago
I actually agree with most of these - at least for early-stage startups. Using off-the-shelf tools has nothing to do with barriers to entry; if you're reinventing the wheel for things that aren't at the core of what differentiates your product, you are just wasting time. As important as they are, reducing technical debt and improving security are not the highest priority items - especially when you have limited resources and a yet-to-be-proven product. And yes, soft skills often do influence a startup's success more than code.
- jackmott 10y ago
  You know that actual wheel has been, and continues to be, reinvented constantly.
- fsloth 10y ago
  I would claim using an existing programming language on a commodity platform is good for the wheel analogue. Beyond that searching religiously for ready made solutions with decision not to make it inhouse is just asking for trouble (one needs to approach technological problems with an open mind).
- emblem21 10y ago
  King: Here's some land for you to work on. Serf: But we don't own it. King: You need to improve your soft skills. Serf: Sir, we don't own it. King: You need to realize that you're going to starve if you don't start farming now. Serf: Sir, how much of the food will you take for working on your land? King: Don't worry about the agrarian debt or vendor lock. Think of me as a land-as-a-service provider. Serf: But... King: I already have deals with farm tools to offer you at a discount! $40 a month with $0.01 per pound of food created! Also, friendly reminder of soft skills.. Serf: Well, sir... I... I guess my farm has yet-to-be-proven... You can't differentiate your product if you are the product. Tech service startups are just renters of digital property they can never own. They're the street shops of the internet.
  - dpc_pw 10y ago
    Poor analogy. Virtual land is unlimited. You can get your servers quite fast if you need to. Plus being a commodity, prices race to the bottom, and if designed right, you can swap you "landlord" rather easily - move your dockers elsewhere.
FLUX-YOU 10y ago
Bonus: * Product must scale. You are not allowed to write code that will scale before we actually need to scale.
joelrunyon 10y ago
Flip side - people (read non-technical execs) deciding to build stuff themselves - and hiring a ton of developers just because they've raised money & can. One startup I consulted with - was able to replace a broken e-commerce platform ($M+ in 18 months) in one week with a shopify platform and some custom development.
mgrennan 10y ago
BS - A lot of good stuff started as homebrew tech. GoPro for example.

JoeAltmaier 10y ago

Re: No homebrewed tech Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not smart enough to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.

ben_jones 10y ago
"Can that corner be cut?" "Well technically yes, but..." "Good, cut it" .. 2 years later .. "How could we possibly have been hacked! We had security right?!" .. points behind at ten miles of cut corners ..
- moron4hire 10y ago
  The problem was that the corner could not actually be cut. If the answer is, "yes, but we won't hit our performance targets," then the answer should have been "no, we won't hit our performance targets." Your management can't help it that you said it was possible.
  - 12931831 10y ago
    You should look up what "technically" means in that context.
  - JoeAltmaier 10y ago
    In my case, every meeting I had consisted of me saying "We need to know which features and performance goals we can sacrifice." Never got any answer. They wanted it all; they didn't want to pay for it.
    - lj3 10y ago
      Is it possible this was a communication failure not a technical one? I'm guessing your bosses couldn't tell the difference between the old performance level of your code and the new performance level of the off the shelf code. But, I'm betting they could tell the difference in communication styles. I'm guessing you said 'no' a lot and your replacements said 'yes' a lot?
      - jazzyk 10y ago
        >"They wanted it all; they didn't want to pay for it." The above happened on almost every project I have worked for over the years. Q: "Can we take feature x out of the plan?" A: "We can't release the product/project without it" Q: "Can we then add 2 more months to the release?" A: "Absolutely impossible, the client will not accept it" You are correct, the reason is severe (and systemic) lack of communication: Product-roadmap planning either does not involve technical personnel at all, or at least not until the very last minute, when you are brought in to essentially rubber-stamp the plan. Saying "no" takes a lot of courage at this stage, you are seen as incapable/negative. The underlying problem here is that we are seen as mere technicians/workers, not planners or strategists (we are partially to be blamed for this, but that's a separate topic).
        jnbiche 10y ago
        I've also had exchanges very similar to the above. What I think happens is that managers think that we're negotiating. Negotiating for what? I have no idea, but for many managers, it's their default assumption. In fact, we're not negotiating. We're describing the situation to the best of our understanding. Indeed, when often these situations have started to feel like negotiations, I've stopped and emphasized that this is not a negotiation, this is my very best estimate as to what I need to get the job done, nothing more, nothing less. Sometimes this gets through to them.
onion2k 10y ago
Developers should definitely write their own code when there isn't an open solution that they can leverage to solve the problem, but those situations are quite uncommon for the majority of startups. Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design[1]. Building a business around that is much, much easier and cheaper if you write less of your own code. Use open solutions where you can, and don't use them where you can't. [1] That is in no way denigrating startups that do that. If you can solve people's problems by making a better form then that is a Good Thing.
- exolymph 10y ago
  The way I like to put this — or a related concept, at least — is that no business should waste time building the aspect of its product that isn't the differentiator.
- nostrademons 10y ago
  > Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design They should probably ask themselves what sort of defensible competitive advantage they're building, though. With many founders I know, the answer is "none". This is probably necessary in the very early seed stage - it's hard to build something unique and difficult and still get to market - but it's disturbing how many companies end up with $50M in funding and the answer is still "none". Probably a good indicator of a shake-out in the SaaS world in the near future.
  - Hydraulix989 10y ago
    Network effects are a good example of something that is both non-technical and defensible. You can't build the next Facebook anymore because everybody's friends are already on Facebook.
  - onion2k 10y ago
    The competitive advantage those companies have is typically two-fold: knowledge and brand. Knowledge is the very detailed and insightful understanding of what their industry needs at the moment, and where it needs to move to in the longer term. Founders who build those businesses are typically experienced in their industry and are solving a pain they've seen firsthand. That is exceptionally hard to compete with if they're good. Just because that knowledge can be codified in a 'simple' CRUD app doesn't make it any less valuable. The brand advantage is comes from being the first mover. If the industry knows your company, trusts that you've proven to have an impact on their bottom line (or their competitors bottom line), then you're probably in a good position to retain customers and build a market. Competition is not a problem for a business that's intent on making a market $100m bigger rather than trying to take $100m of business from someone else. Neither of those advantages require any code.
chrismarlow9 10y ago
The real kicker here is development at scale. Anyone that comes in has to learn how all that custom code works, and chances are if you're like any startup I've interviewed/worked at (20+), you don't have any documentation on the code, or it's so out of date it's useless. Meanwhile if you use that "off the shelf" thing and introduce a few hacks to make it work for your use cases, all I have to learn is those hacks and why they're there. The rest is already documented and maintained by another company who built this dev tool.
- wtetzner 10y ago
  > The rest is already documented and maintained by another company who built this dev tool. Or more likely it is someone's open source project on GitHub, and is just as poorly documented as something in-house would be.
  - chrismarlow9 10y ago
    This is something that should be taken care of when vetting the project on whether or not the company should use it. Anyone whos been around that block a few times knows to look for: - current dev status (hasnt been updated in 6 months? probably shouldnt touch it) - community review (is anyone else using it, hows it working for them?) - limitations (this one is pretty obvious, technical limitations/benchmarks/etc) - code quality (unless its a third party service you pay for you should be able to see if the code is worth a crap pretty easily). - vendor lock (if we need to change, how easily can we change? do they use open source protocols/standards that other tools understand?)
    - wtetzner 10y ago
      But this is the point. There is no good rule for when you should use a library, and when you should build your own stuff in-house. It always depends on the specifics of your situation. You need to think about things like the quality of existing third-party solutions, and how well they will fit into your codebase. You might find a third-party library that is 90% of what you need, but there just isn't a good way to get to the other 10%, and so sometimes even in those cases it makes sense to roll your own. Other times I see people rolling their own versions of stuff, and it's clearly much worse than readily available libraries. You just have to look at the specific situation to determine the right thing to do.
ktRolster 10y ago
It's worth remembering that their is also cost involved in using someone else's code. Use it when the benefits outweigh the costs.

deleted 10y ago

[deleted]

ryanlm 10y ago

That sounds like this one guy who is trying to get me to work for free for his "company". "What kind of cyber security does your server have?" Speaking to me in buzz words is a huge red flag.

crpatino 10y ago
It is a perfectly good question to ask for the VC-type about to write a check to the one-guy you mentioned. The fact that you do not speak their dialect does not make their communication any less meaningful. If anything, it means you will always be working for some one-guy or another, instead of being the one-guy.
- ryanlm 10y ago
  I understood his communication. He isn't a VC. If a VC asked me that I would know how to make an appropriate response. I'm also not fully aware of what you mean here.

dperfect 10y ago

I actually agree with most of these - at least for early-stage startups. Using off-the-shelf tools has nothing to do with barriers to entry; if you're reinventing the wheel for things that aren't at the core of what differentiates your product, you are just wasting time. As important as they are, reducing technical debt and improving security are not the highest priority items - especially when you have limited resources and a yet-to-be-proven product. And yes, soft skills often do influence a startup's success more than code.

jackmott 10y ago
You know that actual wheel has been, and continues to be, reinvented constantly.
fsloth 10y ago
I would claim using an existing programming language on a commodity platform is good for the wheel analogue. Beyond that searching religiously for ready made solutions with decision not to make it inhouse is just asking for trouble (one needs to approach technological problems with an open mind).
emblem21 10y ago
King: Here's some land for you to work on. Serf: But we don't own it. King: You need to improve your soft skills. Serf: Sir, we don't own it. King: You need to realize that you're going to starve if you don't start farming now. Serf: Sir, how much of the food will you take for working on your land? King: Don't worry about the agrarian debt or vendor lock. Think of me as a land-as-a-service provider. Serf: But... King: I already have deals with farm tools to offer you at a discount! $40 a month with $0.01 per pound of food created! Also, friendly reminder of soft skills.. Serf: Well, sir... I... I guess my farm has yet-to-be-proven... You can't differentiate your product if you are the product. Tech service startups are just renters of digital property they can never own. They're the street shops of the internet.
- dpc_pw 10y ago
  Poor analogy. Virtual land is unlimited. You can get your servers quite fast if you need to. Plus being a commodity, prices race to the bottom, and if designed right, you can swap you "landlord" rather easily - move your dockers elsewhere.

FLUX-YOU 10y ago

Bonus: * Product must scale. You are not allowed to write code that will scale before we actually need to scale.

joelrunyon 10y ago

Flip side - people (read non-technical execs) deciding to build stuff themselves - and hiring a ton of developers just because they've raised money & can. One startup I consulted with - was able to replace a broken e-commerce platform ($M+ in 18 months) in one week with a shopify platform and some custom development.

mgrennan 10y ago

BS - A lot of good stuff started as homebrew tech. GoPro for example.