Step One: Preparation
If I was going to do this, I needed to study each leg of engineering, from mechanical engineering to cloud infrastructure. I was essentially building my own datacenter, but with 3D Printers instead of servers. I was hyped.
I started with 3D Printers because additive manufacturing was much easier logistically, but harder technically. I knew my strength and passioned lied in tech, but let’s break down the reasoning first:
3D Printers are small, modular, and can work autonomously for hours. They are cheaper than laser cutters and can operate reliably for hours if the environmental parameters are tuned well (see our 3D Printing Blogs for more information). However, the going per-hour profit for them is small and not profitable until you’re at scale.
Laser cutters operate much faster and their control code is much easier since it’s just 2-D, but logistically, you need to add materials more often, with different sizes, different settings, different tolerances and logistics. Laser cutters also had a large variance on cutting time, so they weren’t as autonomous.
I needed a larger factory before I could prove out the autonomous laser cutter facility, but an autonomous 3D Printer could be done in my living room.
So I settled on an online 3D Printer farm.
Now I had to think about the minimal viable product.
Step Two: The MVP
To answer this question, I thought a lot about why people go to datacenters instead of hosting their own local server. Why was AWS important to a software engineer and how could MakerFleet be important to a hardware engineer?
Trading Capital Expense for Variable Expense: MakerFleet made sense. Instead of one company spending thousands on 3D Printing and management, they’d pass it off to us and only pay on a pay per use model. A company’s variable expense would also be much lower as they didn’t need to pay for one person to maintain the printer.
Increase speed and agility: MakerFleet needed to get people their product as quickly as possible. We needed to allow companies to move faster, which meant providing fast delivery. We started planning on how we could provide same day delivery to those near to us.
Benefit from massive economies of scale: People could build their prototypes at scale for much cheaper and faster than if they bought the equipment themselves.
Stop guessing capacity: This didn’t make sense as a parallel. Hardware engineers don’t really need to guess capacity when they’re prototyping at scale. If they’re profitable beyond what we can provide, that’s good. We can connect them to manufacturers.
Stop spending money on running and maintaining the data centers: Maintaining 3D Printers becomes a huge hassle that the majority of people don’t really want to spend time on it. But we’re passionate about fixing 3D Printers, so for us, that wasn’t a problem.
Go Global in minutes: This didn’t make sense to focus on right now. Modular factories around the world sounded cool and futuristic, but not what we could do for a MVP.
There were also things that weren’t mentioned here:
Direct connection to the process: People didn’t need to have an ethernet cable to ssh into their servers. They just needed an internet connection.
Control and ownership: The ability to have ownership and control was extremely important to engineers. They need to know where they’re wrong and where the machine is wrong.
Access to 3D Printers from anywhere: You didn’t need to be close to a 3D Printer to immediately start a print. That was a huge gain because that reduces the barrier for people to start printing.
Requirements of the MVP
It needed to be scalable on an infrastructure and logistic level: Adding printers, removing printers, and fixing them should all be automated and simple.
It needed to be easily managed through the cloud: I needed to be able to watch the factory without being physically present.
Users should have control of the process: Users should feel like they know when their prints are starting, when their prints will begin, etc.. They should feel as connected to the process as possible.
Users need to be able to learn from the process: Like how AWS teaches how to make their process better, users should be able to learn so that it’s easier for them to build their models at scale.
Frictionless: It should feel much easier to start 3D Printing using our platform than any other platform.
Then I moved from requirements to deliverables
It needed to be scalable on an infrastructure and logistic level: Each piece of the factory would be modular, from the adding of printers, to the firmware, to the servers that ran on top of it. Everything should be easily modified. I should also be able to run a “virtual” factory on my laptop so that I could work on it and figure out logistics.
It needed to be easily managed through the cloud: I needed streaming cameras on every printer so I could manage all of them. I also needed to write a control server that would manage the fleet of 3D Printers.
Users should have control of the process: I needed a streaming camera on each one so people could watch the print and see where it went wrong, if it did. Users could also cancel the print if they found something wrong. I also needed to write a gcode visualizer so people could see the exactly what the printer was building.
Users need to be able to learn from the process: I needed to write blogs that taught people about the design decisions so they could get their models right the first time.
Frictionless: The UI needed to work with people who knew nothing about 3D Printing and have a “One Button Press Print and Done” for most prints. People that knew nothing would have a better idea of what needed to be done.
Step Three: Build it.
I couldn’t test out the idea until I had built it. I knew it was important; I knew it would help customers, but I also knew I could be wrong.
But the bug in my head shouting that it needed to be built got too big and I had to do something about it.
So I quit my job and started building the day after. I’m not going to write about the late nights and hard work I poured into understanding how to build software. But just as a side note: Ironically, being a computer science graduate doesn’t necessarily mean you know how to write software. But nowadays, you can learn basically everything from the internet and the local library (I highly recommend studying github code from really good engineers. The way they think about code is truly beautiful).
Two months later, I luckily got into the Harvard Innovation Lab’s new program Launch Lab X, which I figured would be my pilot. If hardware startups at the i-lab started using my farm instead of the other 3D Printers the Innovation Labs had, this idea could just work.
I wasn’t able to move into Harvard until September, but I wanted to launch in August. I focused on the most important deliverables and focused on launching in August. So every day, I coded and studied until I fell asleep and made small steps towards the launch.
August came and I grew impatient. There were bugs that could’ve been ironed out, but I needed feedback more than ever. I had started to get to a point where I didn’t know what I needed to work on; I needed a direction and I knew customer feedback would provide that. So I went to a 3D Printer community forum and asked for volunteers to print on my printers from the cloud.
Beta Launch Day
I hooked up the printers in my living room and sent the url to a few beta users on Facebook.
The volunteers from the forum were printing on my printers from all around the world and were psyched! They could see the stream and watch it all come together! Although the beta was free, the volunteers were sending me money for their finished prints, which was a good sign. The best volunteers gave me paragraphs of feedback on UI, design, and what they found to be the most important pieces of the program.
The day after I beta launched, I got an email from an architecture firm that wanted to print on it. The software was filled with bugs, but we fulfilled their order and got more feedback. At this time, I realized I had enough feedback for another month’s work, so shut down the beta and worked on improving the software.
So I had feedback and paying customers, but was it sustainable? That was a big question. Did people like it more than 3DHubs? 3DHubs has just gotten rid of their “By Makers for Makers” initiative, so cheap, on-demand 3D Printing suddenly had a market. I was also faster than 3DHubs, since there was no person inbetween.
Step Four: Iterate and Feedback
I was afraid that people would still use the previous printers. Many companies had their own 3D printers and even the Harvard Innovation Labs had their own 3D printers. Would they switch? Was the interface worth it?
In September, I moved into Harvard Innovation Labs and found that many startups wanted to use the online printer farm. That was perfect because before we opened it up to the larger community, we needed to be sure our product fulfilled all the issues and problems that we didn’t even know yet. We could sit behind startups using the platform and watch how they interfaced with it all. We could watch our first few customers carefully and ensure we were on the right track.
Luckily, within a week, the other 3D Printers were obsolete and all hardware startups had switched to our printers. The platform was easy to get printing and many startups liked how much faster their hardware prototyping was going. Employees with families liked the convenience of starting a print at home, watching the first few layers from bed, and then spending time with their family, all without being close to the factory. They quickly racked up print jobs on the printers, and we were off.
Now we were getting feedback faster than ever. Back to fixing bugs and adding whatever our customers demanded.