77 comments

[ 2.7 ms ] story [ 124 ms ] thread
This is a really good example of why you need a 'hacker' in your startup, in the traditional 'one who is good at building ad hoc systems' sense. Having awesome technologists who can write brilliant, well-tested and robust code is certainly useful, but a lot of the time in the early stages of a company you just don't have time. You have a problem and it needs to be solved fast. Most things can be fixed later when the initial traction turns in to cash. Until then, hack all the things.

Note: I might be biased because hacking things together is what I'm good at.

When you've got a person who can hack a good prototype together and then later use the lessons learned to develop a fantastic quality software system, you're in luck.
This is true. But, it seems a waste for the hacker to spend so much time working on a problem that would already be solved if they used a vendor that specialised in what they wanted to achieve.
... Or just should a fulfillment provider that is halfway competent. Perhaps one that isn't doing you a favor and actually does similar stuff for other people.
The point is that you can't really predict what you're going to need. Someone in the business who can pick up a problem and solve it fast, even if the solution is a hack you'll replace later, is useful. Having them around means you don't miss opportunities you'd otherwise have to pass on.
Sure, but in this instance you can 100% know what you need--a shipping fulfillment provider for B2C sales. There are hundreds to choose from, they didn't choose one.

They are happy and proud, but their slow shipping and fulfillment disappointed much of their customer base and surely cost them a lot of sales. I'm not even a customer and I knew that they were a clusterfuck. Their $500 hack probably cost them at least 100x that in revenue.

Hackers are great and valuable, but sometimes you don't need a hack you need competence.

This was really interesting, but it just seems like they chose the wrong fulfilment partner for their warehousing and logistics. I work for a third party warehousing and logistics company in AU, but we specialise in receiving orders from external parties in electronic formats and providing tracking information back to the orderer. People think that warehousing/distribution companies are all the same, but there are a lot of different niches. Some are strong with bulk shipping, some with small and fiddly picking, some with large national campaigns that need simultanous delivery. You need to do your research and look for which suppliers are being used by other companies that have a similar distribution profile to you.
Yeah, that does raise the question of why they chose a company that doesn't normally do what they were looking for in a fulfillment center. It never really covers why exactly they chose Heritage Paper over a different company that focused on smaller ecommerce orders instead of freight.
Yep. This is 100% right.

I've got warehouses that send me things in EDI. I've got warehouses that have me pull something down over sftp in csv or xml. I've got warehouses with bizarre SOAP apis. I've got warehouses with bloody custom REST APIs [that probably cost them $10,000+] sitting on a mac mini that sits in their office.

Your comment really should be at the top since this blog post is little more than a warning of "Pick the right fulfillment house or it'll eat 6 months of your life"

Does anyone know how to get around that Excel CSV issue, where Excel will "helpfully" convert a number-like value into a meaningless value in scientific notation, even if the number was quoted like "1234"?

That was a huge pain point in a previous work that I did.

If you put an apostrophe in front of the number it will store it as text but will appear as a number.

Just to be clear - you can then save the xls/xlsx to csv and the csv won't contain the leading apostrophe, but will show the whole number.

If you put the apostrophe in front of a number, and save it as csv, that works. But if you reopen that exact same file, Excel will still misinterpret the number.

The issue here was that there's no way to let Excel know that this value in this CSV file is not a number. The only way around it that I know of is to stick with xlsx, which has its own pain points.

Yes, it isn't ideal.

What you can do is put 2 apostrophes in front of the number in xls/xlsx and save it to csv. The conversion will drop one apostrophe and when you open the csv it will still have one apostrophe in front of it followed by the whole number. Then you can use a formula like =RIGHT(A1,LEN(A1)-1) to remove the leading apostrophe. The number generated by the formula appears as a proper number again and is usable in calculations.

Would it still be an issue with TSV? That's my preferred flat file data format, find it less error prone compared with CSV.
Yes, it's still an issue. I prefer tab separated too, but it still doesn't help you.
"But if you reopen that exact same file, Excel will still misinterpret the number."

No, you can set the import to treat it as a text field. It is really easy and this should not be a problem. The import can define field by field what it should be treated as (most often used with dates).

The problem here is that, like the folks mentioned in the article, I wasn't the one opening the file on Excel. I'm generating a CSV file from a webapp to be sent to clients for processing. They would double-click the file, and see those mangled fields.

The real issue here is that Excel doesn't respect quotes on a CSV file for some inane reason. That is a bug on Microsoft's end.

The way around it is, rather than opening the CSV file directly, to create a new blank workbook and import the CSV file using Data --> Get External Data --> From Text. This opens the Text Import Wizard and from there one can define the datatype for each column - set it to Text (instead of the default, General) and it won't be interpreted as a number.

Another way is to rename the .csv file to be .txt instead, and load it in normally. This triggers the Text Import Wizard upon opening, and the rest is as above.

Also to do this programmatically, one can use the VBA function Workbook.OpenText, and specify the data types via the FieldInfo parameter.

Can't you set the number format on the cell?
It's possible with .xls or .xlsx files, but csv files can't store number formats.
That is why you convert the spread sheet column to a number before you export to csv. The fulfillment center was lazy, when you paste large numbers like that into excel, it auto converts your large number into scientific notation. you simply only have to change the data type of the column and it will change it back to a number. A CSV is dumb, it only exports what Excel displays.
You set the field to text on import. Very simple. Its a shipping number so text is fine.
In the past there would have been a Microsoft Usenet group with "MVPs" (Microsoft Valued Professionals) providing peer support.

I guess the modern equivalent is SuperUser stack exchange?

So far there's this, which doesn't answer the question: http://superuser.com/questions/355108/csv-error-on-phone-num...

And this, which converts numbers into text, but maybe there's an option to keep them as regular numbers not scientific notation?:

http://superuser.com/questions/586306/save-data-exactly-at-o...

> To do this, open Excel first.

> Click on Data > Import from text.

> You will get a window where you'll have to pick the import type. Choose Delimited then next.

> In the next screen, check only comma, then next.

> On this screen, click the first column in the preview box, scroll to the last column. Hold SHIFT and click the last column. This should make all the columns 'black' (you actually selected all the columns).

> Now, click the radio button Text. After that, click Finish and OK to get your data as you wanted it to be!

Hack warning: 1) open Excel 2) open your csv in Sublime or other text editor 3) paste csv into column A in Excel 4) use text to columns to convert 5) select 'text' type for the number columns
Summary: "Fulfillment of physical goods is hard, especially when you don't know anything about it."
I agree, but it makes for a good story. It is amazing how much detail goes on behind the scenes in shipping product. A story like this where "logistics outsiders" re-create this stuff from scratch and then write about it is quite entertaining. Good for them, they figured out something that works and had a fun time doing it.
Don't eat soy.
Apparently Soylent doesn't contain much of either soy or lentils. It's a weird way to name a product. Sort of like making a fruit juice called "BeefPork".

(I know the name is a movie reference. Still doesn't make sense to me.)

> I know the name is a movie reference. Still doesn't make sense to me.

It should, since you recognize the reference, and the name fits perfectly. For me, Soylent Green pretty much the first thing that comes to mind when thinking about this type of product.

Why?
There are various reasons, some of which will require time to checkout. One is that soy is a phytoestrogen [1]. So the studies show there could be some issues with men eating soy at high levels. Googling provides a lot of arguments founded in reasoning for and against. Another issue is that soy requires heavy agriculture and processing [2]. This can harm the environment in much the same macro ways as beef production. The chemicals used in processing soy into tofu and other products can be bad. Again, processing arguments go both ways (though soy is poisonous in its raw form [3]).

So right now many, myself included, advocate minimizing soy. You can't get away from it. Thanks to several US administrations soy is huge business. Just watch it. It might be that its good for you. Right now the soy debate is much like the egg debate of the 80s. I leave you with Lewis Black's commentary on food nutrition: https://www.youtube.com/watch?v=tXS5GBuk-GQ

1 - http://blog.zocdoc.com/does-soy-feminize-men-fact-vs-myth/ 2 - http://wwf.panda.org/what_we_do/footprint/agriculture/soy/im... 3 - http://en.wikipedia.org/wiki/Soybean#Nutrition

Considering that soy is being fed to cattle, by definition, soy cannot harm the environment in the "same" macro ways as beef production. Beef production is an order of magnitude more, and anyone who substitutes soy for beef is doing a favour to the environment.
I get that you don't like this product, but why do you have to lie? There's no soy in it.
Then why do they say there's soy in it? https://faq.soylent.com/hc/en-us/articles/201274745-Vegan-Or...

I can see that there might be soy from the processing plant, but I can't find that information easily on their site.

Here's the ingredients label: http://files.soylent.com/pdf/soylent-nutrition-facts.pdf

Soy or soybeans are not an ingredient in Soylent. It has the "Contains: Soy" allergen label because it contains a small amount of soy lecithin, which is derived from soybean oil. Soylent contains lots of oils/fats, and you mix it with water to drink it. Oil and water don't normally mix well. Soy lecithin is an emulsifier that lets them mix without clumping.

Thank you. I actually wanted to know.

My wife is into clean eating. So we limit soy as part of this trend. However, I'm really lazy about eating (1 meal a day when left alone). So Soylent looked promising in that regard.

Soylent is to soy as javascript is to java.
So it's not only $500, but $500 + John's salary which I think is far higher than this.
Makes a better story like that though. Or even "It cost us 10% of our company to even start shipping out our product, what were we thinking?" (Random guess at equity stake)
Cool story bro, but it give me hives just reading it. "We didn't know anything about physical order fulfilment so we hacked our way into a local optimum, rather than asking anyone who knew".

Or, as we say hereabouts, a month in the lab solves a day in the library.

But it only cost $500! Well, I'm sure that'll come as a lovely surprise come payday when John discovers he's working pro bono.

Also, that product looks disgusting.

I love math where $500 in hardware plus 6 months of engineer salary equals $500.

I am a grad student making about $30k/yr and my advisor still says to figure labor as costing $1,000/day.

Startup math is a bit different.

For example, without that kludge, they wouldn't have been fulfilling orders. So, even if they "wasted" half a man-year, they still made their sales and avoided the cost of, you know, going out of business.

You can't really apply operational reasoning to startups the same way you can to larger businesses--you've got to factor in other things.

(And yes, that is used frequently as a way of deflecting legitimate operational complaints.)

That's not the criticism. They're not cobbling a solution together to prevent bankruptcy, they're cobbling together a solution to an already solved problem. Ecommerce fulfillment companies exist, and they chose a freight company with inadequate technology for their needs. Then they're justifying it by saying they hacked a solution for only $500, when it's really costing $500 + 6 months salary + hurt reputation for an extremely late delivery.

They could've incorporated a company that used EDI (or an API) to tie into their database to process orders much more effectively than hacking together a solution with a store bought laptop.

( http://en.wikipedia.org/wiki/Soylent_%28drink%29 )

Look at the timeline. They only started shipping in like May of '14. This article covers April of '14. They had only run a crowdfunding campaign like less than a year prior. They raised funding (a lot) a year later.

The problem with "but but but they should've used an API or an order-fulfillment company" ignores that, at that time, they very likely were lacking the upfront capital required to setup and guarantee that relationship. The problem with "but but but they wasted a ~salary~" is that, if you looked at their payroll at that time, I'm willing to bet they were being compensated mostly in equity and not market wages.

Again, there is an entire solution space that is strictly better that is also strictly off-limits if you don't have the spare funding.

EDIT:

More to the point, this thread is full of Monday-morning quarterbacking. The fact is, these guys raised $20M, and we're bitching on the internet.

Lots of people make bad business decisions, and I don't want to give them a hard time about the shipping company they chose, especially when they were willing to share the experience in a blog post.

What worries me most is the internal accounting that gets them to $500. I am pretty stingy with the money I spend on my hobby projects, and sometimes it is fun to build things that I could buy for slightly more money. That's ok when the goal is entertainment. If I was at work I would do completely different math, and probably consider a few hours work to save $20 to be a complete failure.

I absolutely agree that your logic is correct, for a grad student or full-time engineer.

But again, early-stage startups != normal business calculus.

Look at it this way:

You've got two buckets, one of cash and one of time. You can fulfill business goals by dipping into either or both buckets. The time bucket continually replenishes at a fixed rate but never change capacity, the money bucket may replenish unpredictably in both amount and time and have its capacity expanded (more employees, capital, whatever). If either bucket goes dry, you lose.

At an early stage, your cash bucket is near empty compared to your time bucket. If you've spec'ed your business properly (hah) and are not too unlucky (hah hah), you will never have a demand that exceeds the total available amount in the two buckets.

So, to fulfill demands, you pull from the time bucket, because it has the greater reserves, and because it'll replenish as every second tics by.

As time goes on, though, the demands outstrip what your time bucket can handle. Your time bucket, remember, never gets larger. But, since your business is growing, the cash bucket has been getting larger, and so you start to fulfill demands out of that bucket, using contractors or vendors or whatever.

Eventually, you are fulfilling demands entirely out of the cash bucket, because you simply will never have enough time to do them in the required timeline otherwise.

The same rule ("gotta fulfill my business demands without emptying my buckets") applies at both ends of a company's lifecycle, but results in entirely different behavior--and that's not bad.

Can't wait for the next product wich can maximize your working time. Because work is the purpose of life ofc. People are so hurry to reach their death...
I'd very much enjoy that product. Not because work is the purpose of life, but because there's so much things I'd like to do and so little time to do it.
Cool story bro + unrelated attack on the product = reddit-level posting.
I came here to get away from reddit but there's definitely a lot of unfortunate overlap commenting wise. I should just stop reading comments but I can't help myself.
"a $500 system that successfully managed the first four months of Soylent shipments."

Successfully is rather overstating it. The shipment of Soylent was delayed by over a year and went at a snail's pace. My shipment was delayed at a rate of roughly one month per month, with it eventually arriving something like six months after the first shipment had gone out, despite being one of the first backers. I can't think of a single metric on which I would call the Soylent shipping process "successful".

To be fair, you receiving the product is technically a success. But I understand where you're coming from.
I actually received my order twice! The second order arrived nearly two months after the first and after subsequent orders had been delivered. Getting a free months worth of Soylent was awesome. I sent a thank-you note to the Soylent team and they were very well humored about the situation.
Wasn't that an issue with the overwhelming demand (and not having sourced enough ingredients) as opposed to shipping issues? I don't think your shipment of Soylent was in transit for six months.
I'm sure it was a combination of a lot of issues. They did have a lot of demand, and with that demand came full advance payments for all of that product, which they got to use interest-free for the entire time from sale to delivery. I'm not trying to say their job was easy, or that the main difficulty was any particular thing. I am saying that the result was a long way from being something that merits this kind of self-congratulatory blog post.
I never even received my order. Had to get a refund about a year later.
Exactly my first thoughts when reading this article. Maybe if they spent $1000 it wouldn't have taken a year and a half past the original estimated shipping date for me to get my order from the kickstarter batch.
Very true. I didn't receive my shipment in a timely manner. I asked for and received a refund. In my case they left money on the table.
Nice article about an awful product. I don't eat to live: I live to eat.
To each it's own. I like to enjoy a good meal every now and then, but day-to-day eating is mostly an annoying necessity. I have better things to do with my time.
"As ridiculous and janky as that initial experience was, it wasn’t like it was a failure on our end or on the other end. I wouldn’t really see this as a shortcoming."

He can only say this because they are profitable. In reality I think they were lucky to have a product people wanted so badly. In the first 12-18 months, most of the complaints by actual Soylent customers about Soylent had nothing to do with the product itself, only the fulfillment.

While I enjoy such war stories and love hacking ad-hoc systems myself, I can't help myself not to think how much time they wasted instead of going to someone familiar with shipping industry. There is a saying in my home country: "Not everyone can sing through the vilage!"
Does anyone know why an off-the-shelf solution like Magento or Shopify paired with a label printer wouldn't have worked? It's interesting to see the the mechanics of an early-stage startup, but this feels like a largely solved problem? Also, how did the mess of labels get matched with the specific orders, someone was just matching invoices and stickers?
Before reading the article, I was thinking 'have these dudes not heard of ShipStation?!?' But yea, to answer your question, yes, shipstation + shopify works brilliantly. One person can process and ship 60 orders in 30 minutes. 60 orders via a 3rd party warehouse with all their fees, would run you ~$150 - $200.
Thanks! I'm still a little bit confused about the problem they're solving, but I'm glad to know I'm not crazy :)
Probably because it's not a real problem, they created it entirely themselves. At least they solved it!
"A UPS tracking number is 15 digits or something like that, but a FedEx tracking number is 24 digits. If you opened it in Excel it would truncate it, because it would be like, “That is a 24-digit-number. We should store this in scientific notation.”"

I am stunned that this is actually an issue even when dealing with CSV and Excel. It is quite easy to store numbers in Excel and treat them as simple text.

Nope, this is a legitimate Excel issue when opening CSVs in Excel. If you know a fix without editing the cell data type and saving back into Excel format, I'm all ears!

Edit: I'm referring to the way that most people open CSVs in Excel, by clicking on the file and having Excel be the default CSV program, not by importing it. Is there a way to turn off the scientific notation for good?

You edit the data type because it isn't a number your importing, its a shipping tag. On import you set the column to text, its right there in the import dialog.
ID handling 101 - just because it's made only out of digits, doesn't mean it's a number.
How true that is, dealing with trains, barges, and government issued ids will teach some seriously valuable lessons on that score.
Excel really is horrible at handling anything that needs to feed into a software system that isn't also built on Microsoft technology. Just yesterday I was trying to get a coworker to manually order some rows in a database that I had exported to CSV by date, the problem was that some of the dates were just month-year, and some were month-year-day.

Excel insisted on formatting the columns as dates and the month-year rows would turn into month-year-day columns, turning the year into the day and using 2015 as the year.

I told him to just open up the file in a text editor, as I didn't feel like trying to figure out Excel's interface for him or coach him through an LibreOffice install.

If the person I'd needed the info from was not in the organization, as this situation had been, I'd have considered the approach unworkable and figured out a different way to get the info I needed, as they did. Figuring out and teaching people how to use Excel is not how I want to spend my time.

Well, a lot of people use Excel to prep data for other systems and it really isn't that hard to handle. Perl has excellent libraries for reading and writing Excel spreadsheets. Excel is really easy with a large amount of training material. Even the Perl libraries are very easy to use.

I would never tell a user to open up a text editor on tabular data. It is too easy to configure Excel to do the right thing each time. Basic spreadsheet formatting takes care of a lot of problems.

Let me know when Excel can do real Unicode. Ruby rejects CSVs made with Excel's default Unicode export. I had to sit with my boss last year trying out different ways to get it to work right, and eventually made him use LibreOffice to do the xlsx -> CSV conversion.
Let me get this straight. Your boss's preferred tool outputs a CSV that is rejected by your tool's CSV import and your solution is to force your boss to do the conversion in another piece of software? You being a developer and your boss being a business user doing his/her work in his/her tool. That tool being one of the biggest selling programs of all time for business use.
Yep. It was much easier than writing a layer to translate Microsoft Unicode into real Unicode. But he wasn't a business user. I wouldn't dream of telling the business users what tools to use to get me the information I need. Not because I can't, I absolutely can, but because if it's a business use case, it's worth engineering a real solution. This was just a temporary hack to get us through a tricky data problem. Installing it on his machine and working out a procedure took 10 minutes. Would have been quicker if his machine didn't have the characteristic slowness and inscrutability that Windows machines operated by non-techies exhibit. That procedure carried us through until I could work out a saner way.
meh. I saved $10 million with a perl script and an army of zebra printers.