Peter Reinhardt

Over-Regulation is Doubling the Cost

2025-11-20T06:35:58.474Z

After building a software company to a multi-billion dollar exit, I made the jump to hardware. Now I’m working on carbon removal + steel at Charm Industrial</a>, and electric long-haul trucking with Revoy</a>. It’s epically fun to be building in the real world, but little did I expect that more than half the cost of building a hardware company would come from regulatory bottlenecks. Despite a huge push for climate fixes and the bipartisan geopolitical desire to bring industry back to the USA, I’ve been shocked to find that the single biggest barrier—by far—is over-regulation from the massive depth of bureaucracy.

Hardtech companies of all flavors are being forced to burn through limited capital while they wait for regulatory clarity and/or permits. This creates a constant cycle of cost increases that ultimately flows to consumers, it lowers investment in the US manufacturing and industrial base, it delays innovative new hardware getting into the hands of consumers and businesses, and at the end of the day, it leaves us all worse off, stuck with a quality of life pegged to technology developed decades ago.

Regulatory delays and bottlenecks have added millions of pounds of pollutants like PM2.5, NOₓ and CO₂ to our air from the continuation of business as usual, instead of the deployment of clean technologies from my two hardtech efforts alone. While CO₂ is a long-term climate issue, PM2.5 and NOₓ are immediate major drivers of asthma and excess morbidity. Both operations have high bipartisan appeal—and we’ve never been denied a permit—because we’re fundamentally cleaning up things that matter to everyone: dirty air, wildfires, orphaned oil wells. Revoy is also helping deflate the cost of long-haul freight. But none of that has made getting freedom to operate easy. For creative new technologies the default answer is “no” because there isn’t a clear path to permitting at all, and figuring out that path itself takes years — time that startups can’t afford to wait.

Regulation obviously has a critical role in protecting people and the environment, but the sheer volume, over-specificity and sometimes ambiguity of those same regulations is now actively working against those goals! We’re unintentionally blocking the very things that would improve our environment. We’ve become a society that blocks all things, and we need to be a society that builds great things every day. The rest of this article gets very specific about the astronomical costs regulations are imposing on us as a society, and the massive positive impact that could be unleashed by cutting back regulation that is working against new, cost-saving, creative technology that could also be making people and the environment healthy again.

To make it concrete: both Charm and Revoy are capital-efficient hardtech companies, but Charm will spend low hundreds of millions to get to breakeven, and Revoy will spend tens of millions. In both cases, more than half of the total cost of building each company has gone to counterproductive regulatory burden. I’m hellbent on pushing through these barriers, but the unspoken reality is that our regulatory morass is the deathbed of thousands of hardtech companies that could be drastically improving our lives. We must unleash them.

$300M in Societal Cost & $125M in Burden for Charm</h2>
Charm produces and delivers verified carbon removal to companies like Google, Microsoft and JPMorgan. Charm’s breakthrough was realizing that you could take CO₂ captured in farm & forestry plant residues, convert it into a carbon-rich, BBQ sauce-like liquid (it’s literally the smoke flavor in BBQ sauce), and inject it into old oil wells to permanently remove carbon from the atmosphere. This has all kinds of co-benefits like reducing the massive overburden of wildfire fuels, cleaning up & plugging nasty orphaned oil wells, and improving PM2.5 and NOₓ air quality by avoiding that biomass being burned instead.

And yet… there was a hangup: what kind of injection well is this? Should it be permitted as a Class I disposal, Class II oilfield disposal, or Class V experimental? This question on permitting path took four years to answer. Four years to decide which path to use, not even the actual permit! It took this long because regulators are structurally faced with no upside, only downside legal risk in taking a formal position on something new. Even when we’d done an enormous amount of lab and field work with bio-oil to understand its safety and behavior at surface and subsurface conditions. A regulator faces little cost to moving incredibly cautiously, but a major cost if they approve something that triggers activist pushback.
In the end, we’re grateful that—eventually—a state regulator took the reins and reviewed, managed, and issued the first-ever Class V bio-oil sequestration permit, through what was still an incredibly complex and detailed 14-month review process.
Now imagine that, instead of the 5.5 years from first contact to issued permit, it had only taken the 6 months it actually required to get everyone across the regulatory establishment to agree on a Class V pathway, we would have had 5 additional years operating the well. That’s the equivalent, from our real supply chain, of sinking at least 30,000 tonnes of carbon per year at $600/tonne. Looking only at this one aspect, this delay came with a $90M price tag for Charm. We’ve also spent untold millions on regulatory affairs at all levels of government, not to mention the missed acceleration in sales, and other direct hard costs spent in R&D and processing bio-oil for inefficient and expensive injection into salt caverns instead.
But the public health burden created by this regulatory slowness is where it gets really crazy. This one regulatory delay meant we all got subjected to decreased air quality from an additional 30,000 tonnes per year of pile burning. The resulting particulate emissions alone are estimated to have caused a mindblowing $40m/year in healthcare costs. This is $200M in additional healthcare burden over those five years, mostly borne by Medicare and Medicaid. There are additional costs to NOₓ emissions and more that take it to $300M.
In total, the total cost to society of this single regulatory delay will be about $400M: $120-150M of unnecessary cost to Charm, and the bulk of it—$300M or so—borne by the public in healthcare costs. I’m not sharing these numbers to complain or make excuses; Charm is still on the path to having a huge impact and we’re among the lucky few that can survive these delays. What pains me most is the 5 years of lost carbon removal and pollutant reduction, and the compounding effect that has on all our health and healthcare costs. Over-regulation is now working against the very things it’s intended to protect.
Regulators do their absolute best with the system they have, but the combined effects of: (1) extremely detailed and complex regulation, (2) chaotic budgets and understaffing that disrupt an efficient process, and (3) endless lawsuits against regulators since 1970s-era Naderism have created an atmosphere of fear. If we want to solve the climate crisis, build abundance, lower costs, and generate wealth for all, this has to change. We need to delete and simplify reams of regulations. We need to pay regulators well, and we need to trust our regulators to operate quickly and decisively by putting reasonable limits on endless activist legal challenges.
>$25M in Unnecessary Burden for Revoy</h2>
Revoy’s breakthrough was realizing that you could lower long-haul freight costs and electrify long-haul semi trucks by leaving the diesel tractor in place and dropping an electric powertrain onto the back of the semi. Today, we boost semis from 7 mpg to 120 mpg, driving a 94% reduction in fuel consumption</a>. This slashes emissions that negatively impact both air quality and climate.

And yet again… a hangup: what exactly is this electric doohickey? Is it a truck? A trailer? Something else? It was clear from the regulations that it was a “converter dolly”. But getting complete alignment on that simple fact across an alphabet soup of government agencies spanning both federal and state—NHTSA, FMCSA, FHWA, state transit authorities, air quality management districts, state DMVs, highway patrols and more—took years.
A “powered converter dolly” isn’t even a new thing! Here’s one from the sixties that ran on diesel to help trucks get over mountain passes:

There were some bright spots. The Federal Motor Carrier Safety Administration (FMCSA) and the National Highway Transportation Safety Administration (NHTSA) quickly converged on informal definitional clarity, and then eventually a Highway Patrol Captain who was eager to get innovative electric vehicles on the road pushed it through with a state DMV to register the first four Revoys. But bringing along the rest of the agencies, and the rest of the states, was not fast. It delayed deployments, soaked up hundreds of thousands of dollars of legal and lobbyist time (not to mention all the corresponding time on the government side that all of us taxpayers have to bear), and maybe most importantly… even with a formal memo from the Federal DOT, it is still not 100% resolved in some states.
As one example, one state agency has asked Revoy to do certified engine testing to prove that the Revoy doesn’t increase emissions of semi trucks. And that Revoy must do this certification across every single truck engine family. It costs $100,000 per certification and there are more than 270 engine families for the 9 engines that our initial partners use. That’s $27,000,000 for this one regulatory item. And keep in mind that this is to certify that a device—whose sole reason for existence is to cut pollution by >90%, and which has demonstrably done so across nearly 100,000 miles of testing and operations—is not increasing the emissions of the truck. It’s a complete waste of money for everyone.
And that $27M dollar cost doesn’t include the cost to society. This over-regulation will delay deployment of EV trucks by years, increasing NOₓ and PM 2.5 air pollution exposure for many of society’s least well-off who live near freeways. The delayed deployment will also increase CO₂ emissions that threaten the climate and environment. Revoy’s Founder (Ian Rust</a>) and I actually disagree on what exactly it is about the regulatory environment that needs to change, but we agree it’s completely broken and hurting both people and the planet.
In every interaction I have with regulators, I’m reminded that they’re good people doing god’s work operating in a fundamentally broken system. A regulatory system that structurally insists on legalistic, ultra-extreme caution is bound to generate a massive negative return for society.
If we had a regulatory system that could move fast to experiment with creative new technologies, we’d live in a world where our environment gets cleaned up faster, where awesome new hardware was constantly improving our lives by making things better and cheaper, and where large-scale hardtech innovation happened here at home in the USA, not in China.
As we collectively work to build more manufacturing capacity at home and build the next wave of technologies to power the economy, we need to grapple with the real bottlenecks holding us back. I hope other hardtech founders will publicly share more of their stories as well (the stories I’ve heard in private would shock you). Props to Blake Scholl for doing so</a>.
We need a come-to-jesus about regulatory limits, timelines, and scope. Yes, we need basic and strong protections for clear harms, but we need to unleash every hardworking American, not just a few companies with massive funding, to invent and build hardware again. We need to combine many approaches to get there: expedited reviews for new technology, freedom to operate by default, permits by right-not-process, deleting as many regulatory steps as possible, and more. CA YIMBY</a>’s successful push to pass a deluge of housing acceleration laws in the past two years could serve as a model. America building things again is the foundation of a prosperous, powerful, and clean America.

Judging Product Market Fit

2016-10-18T23:16:38.000Z

In the past few years we’ve tested many different product ideas with Segment’s customers to see what resonates with who. Finding product market fit with new product ideas is simultaneously tricky, and obvious in retrospect. And you can waste A LOT of time pursuing false positives during the tricky bits. But I’ve never had such a stark demonstration of this odd juxtaposition of tricky and obvious as a recent meeting with a large ecommerce company.

We were meeting with this ecommerce company’s head of digital architecture, walking through five new concepts, testing how each one resonated with the company's needs.

For the first concept, he nodded and said “mmhm, that sounds super useful.”

For the second concept, he asked a clarifying question and said “wow, got it, yes I definitely understand the value.”

For the third concept, he said “I see how other companies would find that super valuable, but we have an internal team that takes care of that today.”

For the fourth product concept, he said “Very cool! That’s elegant and makes a lot of sense.”

If the meeting had ended then, it would have been completely impossible to discern the relative product market fit of the first, second and fourth product concepts. Or whether any of them fit at all. With a little more digging, some slight differences emerge, but you could go back and forth all day debating whether they really needed it or whether he was being nice.

Then, we presented the fifth product concept, and he said “Wait, so you’re saying you can do X? Wow hmmm… that’d be huge for us. That’s something we haven’t been able to pull off and we’re considering spinning up a team to focus on that. [Turns to another teammate in the room.] Can you set a followup meeting with so-and-so, and make sure this gets presented to other-so-and-so, we should fast-track this and get a full demo rundown and technical details of this ASAP.”

Ah. 🚨🚨🚨 that’s product market fit.

We were immediately backpedaling to explain that it wasn’t built yet, and asking him to slow down for a sec to tell us more about why this was important to them. It had switched from us pushing to the customer pulling.

The other three questionable product market fits that seemed so tricky to interpret are all obvious “no”s in retrospect. When he said he understood a concept was valuable, and saw that it was technically cool, he didn’t actually mean “We have this problem and need a solution.”

It’s always obvious in retrospect. If you feel like you need a psychic to read the situation it’s just not product market fit. The customer has more dynamic range in their feedback than you think… when you hit something painful they’ll really jump. So you need to turn your filter up to 11 out of 10 when you’re searching for real pain. The customer always ends up pulling—ripping(!)—it out of your hands when you hit a real pain point.

At Segment we’ve felt this customers-are-pulling-and-we’re-just-trying-to-fulfill-demand feeling when we launched analytics.js</a>, warehouses</a> and sources</a>. It’s incredibly fun and a bit alarming because you suddenly lose control, and the customer takes control. But for our first year and half we misinterpreted kindness and idle interest as shades of product market fit</a>. So be careful out there, you can waste a lot of time chasing tricky fake positive feedback.

Driving Data as a Defensible Moat for Self-driving Cars

2016-05-17T23:28:59.000Z

In a future where self-driving cars are available for $0.25 per mile with less than 5 minute wait times, the cars are clean, and you control the music… Uber and Lyft both lose their driver-rider network effects and the market becomes a commodity rentals business again</a>.

Or does it? What would be the key competitive differentiator for a self-driving car service?

Safety.

The world is incredibly fixated on the safety of self-driving cars, far more than they are on the safety of human-driven cars. The implacable fear with self-driving cars is that they’ll do something crazy, crash, kill you, maim you or otherwise damage or scare you when you don’t have control. It’s terrifying.

The self-driving car service with the highest safety ratings and a better safety record will simply command a higher price from riders.

For example, would you pay $0.25/mile for 0.01% odds of a crash, or $0.35/mile for 0.001% odds of a crash? I’d choose the more expensive option all day long, because both prices are so low and the cost of an accident is just life-shatteringly awful. But safety doesn’t just command higher prices, it also lowers the fleet’s insurance costs, giving the safest fleet a wider margin on both ends.

Given that safety will be the metric that matters most for self-driving car fleets, which company in the mix will win? Who is going to build the safest self-driving car?

The major breakthroughs in AI and hardware sensors will likely be commodities. Google, for example, already open sourced TensorFlow</a>, and the key sensors like LIDAR are generally widely available from electronics manufacturers, with rapidly falling prices</a>.

But there’s another piece to having a great safety track record: you need a TON of data to train your AI. The state of the art in AI is basically to just throw as much data as possible against well-understood algorithms</a> (like neural nets), and incrementally improve the results.

And the availability of training data is not evenly distributed: the bigger the fleet of self-driving cars, the more data you have, which allows you increase safety through better driver-AI, which lets you reduce insurance costs, which lets you keep lower ride prices and higher safety ratings, which attracts more customers. This is a classic economy of scale that creates a significant defensive moat around a self-driving car business.

Now let’s look at how Google, Uber and Tesla stack up when it comes to access to training data.

Google has a few vehicles on the road, and the ability to simulate driving on a massive scale.</li>
Tesla has just over 100,000 vehicles</a> on the road (that have sensors).</li>
Uber has millions of vehicles on the road (but none with sensors sending data to Uber).</li></ul>
Google’s software is appears to be in the lead, but Tesla is arguably building up a pretty formiddable dataset, and Uber has a bunch of untapped potential.
Looking forward, Google should be running simulations like crazy and rushing to get more than just a few test vehicles onto the road. Tesla should be rushing to get more vehicles on the road as fast as possible. Musk just announced they’re accelerating the race to 500,000 vehicles</a> by two years. And Uber should be giving drivers a bonus for installing a sensor pack on their cars, taking advantage of the millions of diverse vehicles and drivers they already have on the road.
The race to accumulate the biggest dataset is just beginning.

Finding Product Market Fit

2016-03-07T00:30:41.000Z

There’s a fine line between the “reality distortion field” founders create and just being a bit delusional. During our first year and half as a company — May 2011 to December 2012 — we were closer to delusional, and this massively extended how long it took us to find product-market fit.

In particular, I so desperately wanted an idea to “work” that I just forced ideas through and never stopped to deeply question whether people really, really had this problem. Eventually though, in December 2012, we had an internal moment of crisis and actually did verify that people had the problem we were solving. At that moment, everything changed, and today Segment is growing quickly, with 6,500 customers and a team of 70 people.

I hope that by sharing our story of finding product market fit, other founders can avoid years of “wandering around lost in the woods” like we did, and emerge with product-market fit sooner.

Lost in the Woods</h2>
Y Combinator’s constant, sage advice is to avoid solving problems that nobody has</a>. It’s the most common startup failure mode, and it was certainly our failure mode for that first year and half.
Here are the three ideas I pushed us to build, all the while convincing ourselves that these were real problems people had:
Bookxor was a tool for students to read and annotate lecture notes. In return, professors could see usage and readership analytics on their course notes. Six months went by at MIT before we realized that professors didn’t really care whether people read the notes.</li>
ClassMetric was a tool for students to press a button to anonymously say “I’m confused!” The professor would get a graph of how confused their students were over time. We spent ~6 months at MIT and at Y Combinator in 2011 building this before realizing that (1) professors often don’t really care how good their lectures are, (2) professors can’t respond to the feedback in real-time anyways, so it only helps them improve next semester (slooooowww), and (3) the students all just went to Facebook and Gmail on their devices anyway.</li>
Segment.io was originally an analytics tool like Google Analytics, except focused entirely on user segmentation (Segment is now a very different product</a>). We spent ~12 months after Y Combinator in 2012 building this segmentation product before realizing that the market for analytics tools was incredibly crowded, and that we didn’t actually understand what problems our customers were trying to solve with more charts and analysis.</li></ul>
In each of these cases, I deluded myself and my co-founders into believing that professors really cared about students reading their lecture notes, that professors wanted deeply to improve their lectures (or that students even wanted to focus during lectures), or even that companies needed better segmentation in their analytics. In fact, all of these ideas were very poorly validated.
Good validation work would’ve looked something like this:
Hour-long interviews with professors and TAs diving into what they found most frustrating about teaching.</li>
Digging and digging until we found a problem we could solve, or even more critically, possibly determining that there were no problems for us to solve.</li></ul>
As engineers who had never done this before, talking to people didn’t seem like real work. Real work was coding. But in reality, 20 hours of great interviews probably would’ve saved us an accrued 18 months of building useless stuff.
Put another way… we were making enormous errors in the “Conception” phase (“ConOps” in the diagram below), but we weren’t correcting it until after we’d done a staggering amount of engineering effort all the way at the right.
</figure>
If you think about odds of a team failing to find product-market fit, it might look something like this (for the sake of illustration only):
Non-technical team: 15% odds of being able to build it, 60% odds of solving a real problem</li>
Technical team: 90% odds of being able to build it, 10% odds of solving a real problem</li></ul>
If you’re a technical founding team like we were, building it is the least useful way to reduce the risk in the company. You should be focusing the vast, vast majority of your effort as a technical founding team on making sure you’re really solving a problem. Because if you are, I’m quite sure you can build the solution.
That said, a really odd thing happens when you solve your own problem</a>: you rarely mess up in finding a real problem! (Almost tautologically.) In the diagram above, you’re unlikely to screw up the Concept or Requirements phase because you already know what the problem is and what you need to solve it.
And this is how Segment as it stands today was discovered. (Slack, Dropbox and all kinds of other companies have similar stories.)
Accidentally Solving a Real Problem</h2>
Let’s rewind to the early days of ClassMetric, at the very beginning of Y Combinator in June 2011. We were just starting to build our lecture tool (for students to say “I’m confused!”) and we figured we should have analytics on it. So we googled “analytics” and found Google Analytics, KISSmetrics and Mixpanel. Their APIs for collecting data and the graphs that each of them provided looked similar… we just couldn’t make up our minds about which one to use. So we wrote a pretty gnarly abstraction that just took an event like “Signed Up” and sent it out to all three analytics services.
Then, a few months later when we were hacking on a music project called Ethertunes, we put our lightweight little abstraction into its own little javascript library, and cleaned it up a bit.
Six months later we were deep into building Segment.io (the analytics service), and we had another idea. People kept telling us they already had Google Analytics installed, so how was Segment.io different? We really wanted to show our analytics service in direct comparison to Google Analytics. So my co-founder Ilya</a> cleaned up our javascript library a bit more, gave it a name (“analytics.js</a>”), added Segment.io as the fourth analytics service it could send data to, and open-sourced it on Github so that prospective customers could give it a spin. Analytics.js started getting some stars on Github, and even a couple pull requests, which was mind-blowing to us at the time.
By December 2012, after a year and half of working on made-up problems full-time (with analytics.js just a side project in fits and starts), we were starting to run out of money. The four of us hotly debated whether we should shut down our analytics service (which had no real customers), try a totally new idea, or just throw in the towel. Then my co-founder Ian</a> came out of left field and said: “You know, I think there’s a really big business behind analytics.js. We should drop all this other stuff we’re working on and focus on that.” I remember very vividly thinking (and probably saying), “That’s a terrible idea. This is a javascript library that’s already open source, it’s about five hundred lines of code… how could you conceivably build a business around that?” But by this time Calvin</a> and Ian had drafted a “manifesto” about the future possibilities that lay beyond analytics.js (surprisingly accurate in retrospect!)
I felt so strongly skeptical that I said something to the effect of, “Alright, before we can go ahead with this, we need some sort of proof that there’s a real problem here.” We decided to build a landing page that just explained analytics.js and the data-routing problem it solved. Then we put the page up on Hacker News. I was expecting it to be completely ignored, and that we’d move on and try something else.
But to my great surprise, analytics.js went straight to the top of Hacker News and got about a thousand stars on Github in that first day.
</figure>
The skepticism and staunch disagreement between co-founders had forced an extraordinarily clarifying test. We already knew analytics.js solved a problem for ourselves, but after the HN launch, it was obvious analytics.js was solving a real problem for other people too. Rather than months and months of engineering effort, all we needed in the end was a landing page built over a couple days. That little open source library (with only 8 incomplete integrations</a>) was our minimum viable product:
</figure>
Or, another way of looking at it… we barely had a skateboard version of the product:
</figure>
But it was a proof point none-the-less. So with that little win in hand, we started expanding scope to solve more of the problem we’d accidentally discovered. Over the next 6 months we added ~40 more integrations, the ability to send data from server-side languages like Node and Ruby, and built libraries to collect data in mobile apps on iOS and Android.
</figure>
More recently we launched the ability to easily load all your web and mobile data into a data warehouse</a>. It’s still very much early days at Segment, and there’s an incredibly large set of problems to solve for our customers. But once we found that initial sliver of a problem, digging in has been incredibly rewarding, fun and challenging in new ways.
My advice from being woefully “lost in the woods” is that if you’re not 100% sure you’re solving a real problem, you’re almost certainly not. Make sure you really validate the problem you’re solving. You’d be batshit crazy not to. It may be an utterly bizarre juxtaposition, but you need to balance your reality distortion field with extreme skepticism to ensure you’re not deluding yourself and moving in a useless direction. Best of luck!

Startup Finance for Founders — Part II, Strategic Finance

2016-01-19T00:37:49.000Z

This is part two of a series outlining practical lessons I’ve learned about finance at Segment</a>. Part I covered accounting</a>. This article covers strategic finance, the exact opposite of accounting. Strategic finance looks to the future, attempts to guesstimate the fuzzy unknowns, and searches for ways to mitigate risk and increase growth.
Strategic Finance</h2>The most dramatic part of strategic finance is fundraising. It’s very exciting to sign your Series Seed/A/B/C term sheet, receive a huge wire transfer, and then see your company splashed across the press headlines. But I won’t discuss fundraising here because others have been over it in great depth. For example, Paul Graham’s essays: How to Raise Money</a>, Investor Herd Dynamics</a>, and How to Convince Investors</a>. Instead, in this article I’ll focus on some untouched practical pieces of strategic finance: when and why we hired a part-time CFO, the importance of annual prepayment, why we decided to avoid venture debt thus far, and how we use a “shadow budget”.
Part-time CFO</h2>
When we were getting ready to raise our Series A, we realized we needed more help with finance. It wasn’t easy pulling together all the financial and legal documents for the fundraise, and our bookkeeper wasn’t prepared to help with this level of financial diligence and strategic thinking (how much to raise? why? based on what parameters?). We really needed someone to own finance as a whole, run a tighter accounting process, and advise us on strategic finance issues like insurance, fundraising, venture debt and growth modeling.
We interviewed five part-time CFO firms based in San Francisco, and ultimately hired Jeff Burkland of Burkland Associates</a>. Without knowing much about CFOs, we were looking for someone who was already teaching us things about finance in the interviews, and someone who was a culture fit. It’s been enormously helpful to have senior financial advice, not just for fundraising but also for thinking strategically about sales, marketing spend, and hiring. Most of the learnings below are things we’ve learned from Jeff.
Looking back now, I feel strongly that if you as a founder are spending any time at all on finance (beyond pitching investors during a fundraise), then you should outsource it to a bookkeeper for accounting, or a CFO for accounting and strategic finance. There’s a lot to learn, and without some experienced financial help, seemingly small projects like “get the insurance we need for that sales contract” can balloon into weeks of research, phone calls and silly delays. With a CFO that time sink just evaporates and you go back to working on real bottlenecks in the business. As my co-founder Calvin says: “Would recommend to a friend!”
Annual Prepayment</h2>
Two years ago our sales advisor scolded me “You should only ever accept contracts with annual prepayment, it makes a big difference for cash flow.” I thought to myself “yeah, ok, whatever. why not!” So we followed his advice (without understanding it), and just went about our business selling contracts with annual prepayment. But we didn’t really understand what “cash flow” meant, so we started to slip. Pretty soon every contract was billed quarterly or monthly, because it was a bit easier to close deals that way.
Well, it turns out that monthly and quarterly billing was a huge nightmare for our office manager Jenn (we didn’t have an accounting team yet). Invoicing monthly and getting people to actually write checks on time every month is just a massive time sink, for you and your customers.
Then one day our CFO Jeff comes to me and says, “hey I want to show you something.” On a single graph he showed me the difference between annual and monthly payments. Here’s a fictional version, showing cash balance over time (based on 17% mo/mo growth in revenue, and 8.5% mo/mo growth in spending, full model here for you to play with</a>). This is the same company, with the same growth, and the same spend… the only difference here is payment terms:
</figure>
See the difference? Monthly payments result in bankruptcy (red) and annual payments result in ample and increasing cash (blue). Growth costs money, and if your customers pay annual up front, they pad your cash balance much earlier in their lifecycle.
Even biannual or quarterly payments lead to the same fate as monthly:
</figure>
The trick here is that if you’re growing quickly (and consistently), then getting paid annually up front funds your growth. This simple change in cash flow is the difference between needing to raise a huge round of financing, and not needing it at all.
From that moment forward, the board made it a policy to only sign enterprise contracts billed annually up front. As a side benefit, this massively simplifies accounts payable for enterprise customers, and simplifies collections for us.
Venture Debt</h2>
It seems to be a reasonably common practice to take on venture debt. The idea is to take out a loan from a startup-friendly bank like Silicon Valley Bank, collateralized against the worst case scenario of an acqui-hire or additional VC funding.
A typical venture debt loan in the several-hundred-thousand-to-low-millions is structured something like this:
No payment for 6–12 months, then paid back over the following 2–3 years.</li>
A loan fee: several thousand dollars in cash and a bit less than 1% equity.</li>
An interest rate a couple percent above the federal funds rate.</li>
Required detailed financial reporting on a monthly basis.</li></ul>
There seem to be a couple common use cases for venture debt: delaying fundraising and funding predictable growth. If you’re confident in your ability to raise venture capital down the road, you can use venture debt to get another 6–12 months of growth under your belt and push up your valuation.
Or, if your business is incredibly predictable and you can confidently say that X dollars invested now will generate Y dollars in 12, 24 and 36 months, then venture debt can be an exceptionally cheap way to fund growth. But you’re making a bet that you’ll keep revenue coming in on a steady beat.
When we were considering venture debt vs. Series A in early 2014, we were just barely starting to have our first revenue over the previous 3 months, and new revenue was anything but consistent. The last couple years have also been a great VC fundraising environment with relatively cheap access to capital, so there wasn’t a huge benefit to delaying a fundraising event. In fact, we were excited to have equity investors join the board (Vas at Accel in the Series A and Will Gaybrick now CFO at Stripe in the Series B — both bring huge networks and incredibly valuable perspective in building the business), and the financial reporting requirements for venture debt seemed a bit onerous. We decided to stick with selling equity, and re-evaluate venture debt down the road.
The two scenarios where I’d seriously consider venture debt are: 1. You need a longer bridge between rounds due to lackluster growth. 2. You’re not looking for active investors, and have highly predictable growth.
Shadow Budget</h2>
Focus, speed and agility are a startup’s best weapon, so internal bureaucracy is a startup’s worst enemy. Budgets implemented without a clear purpose are definitely unnecessary bureaucracy. So we’ve tried to implement budgets only as-needed, to solve specific problems and eliminate bureaucracy.
As we grew past 30 people we started to notice that team leads were nervous to spend money without some sort of approval, or at least a casual “yep, go for it!” That meant we were moving slower on everyday decisions. Our goal was to enable team leads to spend money as they saw fit, without a complex or unclear approval process. We also wanted a reasonable prediction of how much the company was going to spend over the next 6–12 months.
Initially, we tried implementing full-on budgets as a way to get predictability & enable team leads to spend money. The team leads were responsible for putting their budgets together. Unfortunately, this turned out to be WAY too much overhead, at least for a young team that wasn’t yet familiar with budgeting or balance sheets.
Instead, we ended up settling on what we call a “shadow budget”. Every quarter our CFO uses the past month’s expenses and the team lead’s hiring plan to create a model of how much money we expect them to spend in the next 3–6 months. Then the shadow budget for every team flows up into an overall company shadow budget.
Team leads are not accountable to this budget; it’s just a model that “shadows” reality as best we can. It gives us a guide for comparing what we anticipated vs. reality, quickly revealing any surprises. It’s also a chance to familiarize the team with company financials without burdening them with a full-on budget-planning process. Marketing will be the first part of the org to get a full-on budget, as encouragement to continue growing quickly and also a guideline for spending responsibly.

Startup Finance for Founders — Part I, Accounting

2016-01-08T00:41:41.000Z

When we started Segment</a>, we knew nothing about business finance. My background was in aerospace engineering, and my co-founders came from computer science and design. Beyond the hilariously overcomplicated spreadsheet we used to manage grocery bills as roommates, we really had no experience in finance when we started the company.
In the past 2 years Segment has grown from 4 to 60 people, signed up thousands of customers, and raised $44m over a few rounds of financing. Out of necessity we’ve learned the basics of accounting, invoicing & contracts, billing periods, bank account structures, strategic finance and growth models.
But it’s been hard to piece together. Bits and pieces from accountants, lawyers, our CFO and reading a random book or two off Amazon that looked promising. Although startups have developed a culture of sharing learnings, finance generally remains pretty hush hush. Notable exceptions are Everpix’s eye-opening post-mortem</a>, Baremetric’s Open Startups</a>, Mattermark’s complex fundraising tale</a> and oodles of general advice about fundraising. It’s a tricky topic.
This article is part of a two-part series outlining what I’ve learned about startup finance, from a practical perspective. I’ve tried to include diagrams, charts, and redacted docs where helpful.
Part I covers some of our learnings in accounting: accurately recording the past. Accounting is rigorously pedantic to record exactly what’s happened. Then, in Part II I’ll talk about some adventures in strategic finance. Strategic finance is exactly the opposite of accounting. It looks to the future, attempts to guesstimate the fuzzy unknowns, and searches for ways to mitigate risk and increase growth.
Part I: Accounting — Bank Accounts, Credit Cards, Invoices & Contracts</a></li>
Part II: Strategic Finance — CFOs, Annual Prepayment, Venture Debt & Shadow Budgets</a></li></ul>
Accounting</h2>
I learned the basics of accounting from “Accounting for Developers</a>” and this little book</a>, not to actually do the accounting for ourselves, but to understand what our bookkeeper was taking care of for us. As we grew, problems came up that weren’t covered there, like structuring bank accounts, dealing with lack of credit history, and how contracts and invoicing actually work.
Bank Account Structure</h2>
When we were just getting started, we set up a company bank account like any normal person. We opened a checking account. Done!
But then we raised a new round of financing (very exciting), and started to build the team. With $2m in the bank and a payroll to hit, we started to get nervous about that $2m being so easy to access.
Our customer base was growing, and we were giving our bank account number to receive ACH payments from customers… the same bank account that held the entire livelihood of the company in cash! According to warnings from our peers on the ycfounders forum, it’s reasonably common for leaked bank account numbers to get hit with fraudulent withdrawals.
After we raised our Series A and added another $15m to the account, our simplistic checking account structure made us even less comfortable. We needed to be able to spend money easily, but we wanted the majority of the balance set aside securely.
This is when our CFO put in place a new bank account structure.
</figure>First, since our new $15m+ balance was way above FDIC insurance limits (the government insures up to $0.25m per entity, per account type, per bank), cash backed by the bank was no longer the safest asset. We moved most of our cash to a money market account invested purely in US treasury bills, which are considered a bit more secure in case the bank collapses or places a temporary hold on funds during a bank run. You may think this is unlikely, but 140 banks failed in the aftermath of the 2008 financial crisis</a>, and Greece just had a bank run in July. We wanted to be safe.
Second, we created a receivables account that can only accept deposits. The bank simply rejects attempted debits to the account. We hand out the receivables account number to customers with abandon, because it only exists as an endpoint for customer payments. It also makes it easy for accounting to see an isolated list of customer payments.
Third, we created a payables account that we keep more private. We maintain a small balance in this account that comfortably covers daily expenses.
Fourth, we asked our bank to set up an automatic “sweep”. At the end of every day it automatically transfers everything from receivables to the treasury bills account, and refills payables.
This account structure simplified our cash management, so that we spend less time running around making internal transfers. Plus, it gives us better security and reduces financial risk. It’s an easy way to sleep better at night.
Credit Cards</h2>
Many founders I’ve talked to have struggled with banks giving their startups low credit limits. We’ve also been stonewalled, but hopefully this story gives you some negotiating tips. Initially each founder just had a simple debit card, because that’s what automatically came with our checking account. Wonderful! Then we hit a problem: there are limitations to debit cards (e.g. you can’t rent cars).
So, we switched from debit to credit cards to solve the problem. But alas, credit limits for startups are downright draconian. For example, Silicon Valley Bank credit card requires you to pay the entire credit limit in cash, which they hold on deposit, and then they still charge interest if you’re late on a payment. More than once we had late fees when autopay didn’t work.
We switched to Bank of America after that, but were only allowed a laughably low credit limit:
—February 2014— BoA: What credit limit are you looking for? Me: We’ll need at least $20k for our monthly operating expenses. BoA: Ok, I have a few questions. What was your revenue last year? Me: Around $40k. BoA: Got it, what do you expect your revenue to be this year? Me: Over $2m. BoA: Uh huh... [suppressed laughter]… ok, um, I’m going to approve you for a credit limit of $5,000 per month. Me: [hahaha, what am i supposed to do with that? pay it off four times a month?] </code></pre>Every six months or so we had the same predictable conversation with a BoA risk analyst, inching up our credit limit. Ultimately I found we could get more reasonable limits by steering the conversation away from revenue, where high growth startups sound incredibly strange, and focusing instead on our cash balance, which was inflated by fundraising. The line we resorted to (with narrowly suppressed laughter at the absurdity of it) was “We could transfer in a couple million in cash, if it would help?” BoA is not used to dealing with snarky, frustrated startup founders, and the line worked: we got significantly higher credit limits. We were fortunate in being well-funded, and this was a useful moment to flaunt it. Eventually, Bank of America wasn’t able to keep up with our credit limit needs (when we needed to jump from $75k/mo to $200k/mo). And worryingly for me personally, in a disaster scenario I was personally liable for the card balance in lieu of the company. So, we’ve switched back to SVB to increase our credit limit (which they’ll hold on deposit, sigh).Contracts and Invoicing</h2>Two years ago we had no idea how selling to other businesses worked at a operational level. None of us had ever done it before, or even worked at a company that had done it before. We started by accepting payments through Stripe, which was nice and simple. But as our customers grew, so too did the size of payments and the need for customized terms of service. We learned that for software contracts above $20k per year, most companies didn’t expect to put it on a credit card. They expected to be invoiced once, with signed terms of service reviewed by their legal team. So when we started closing our first “business tier” contracts in Fall 2013, we expanded our accepted payment methods beyond Stripe to include paper contracts and invoices. If you haven’t seen this before, here’s the basics of how it works: Contracts are usually structured as a Master Services Agreement (MSA) with one or more Order Forms. The master services agreement covers the contractual agreement about liability, confidentiality, payment and termination. The order form is meant to be an easily readable description of what’s being sold and paid in what timeframe, to whom. Here’s an anonymized order form from Segment:</figure>The master services agreement is designed to allow future orders at the same company (e.g. additional teams or departments) to be executed as quick signatures on a new order form, without another legal review process. This makes it easy for a customer to expand their account, no muss no fuss. We’ve found that the liability terms of the master services agreement are the most hotly contested. No one wants to be on the line if things go south. If you’re selling these kinds of contracts, you’ll likely need to purchase general business liability insurance (and we have extra insurance for data security). From what we’ve seen, insurance for several million in liability seems to start around $10-20k per year. Then, in the contract you hold the line on your maximum liability as the amount you have insured! Invoicing was new to us back then as well. Here’s an example invoice, which simply gets sent to the financial contact listed on the order form.This article covers some of the common practices we’ve learned in startup accounting. The next article will cover “strategic finance,” the forward-looking, predictive part of finance in a startup. It should be posted here in a week or two.</figure>If you’re looking for a great way to do bookkeeping, check out Pilot</a>. A number of companies I’ve invested in have used them and found it incredibly helpful and easy. This article covers some of the common practices we’ve learned in startup accounting. The next article will cover “strategic finance,” the forward-looking, predictive part of finance in a startup. Part I: Accounting — Bank Accounts, Credit Cards, Invoices & Contracts</a></li> Part II: Strategic Finance — CFOs, Annual Prepayment, Venture Debt & Shadow Budgets</a></li></ul> 
Replacing Middle Management with APIs 2015-02-03T00:45:12.000Z There’s a trend in Silicon Valley startups to create a software layer in industries that were traditionally pure human services. Uber and Lyft have created software layers in the taxi industry, 99designs Tasks in the visual design industry, Homejoy in the cleaning industry, and so on. These new software services employ armies of human workers, optimizing their output, productivity and quality while driving price down. The software layer between the company and their armies of contractors eliminates a huge amount of middle management, and creates a worrisome disconnect between jobs that will be automated, and jobs of increasing leverage and value. This software layer generally has three parts: the user interface (UI) for the end customer, a programming interface (API) that actually dispatches a human worker, and a second interface for the worker to execute the task efficiently. The API component is the interesting and slightly disturbing part. For example, Uber has a mobile app (UI) that talks to their servers (API). You can imagine that their servers effectively take three parameters: credit card, drive from, and drive to… and they dispatch a human to do it.uber.drive(card, pointA, pointB); // pseudocode obviously</code></pre>What does that make the drivers? Cogs in a giant automated dispatching machine, controlled through clever programming optimizations like surge pricing? Drivers have often told me that the job grants them incredible autonomy: they can drive whenever they feel like it, and they’ve stopped looking for jobs in finance or construction because the daily freedom is so valuable to them. There’s liquidity in the marketplace that allows them to come and go as they see fit. But the actual driving is perfectly orchestrated by software, and it’s not a secret that Uber intends to eventually replace all their drivers with self-driving cars</a>. I worry that the army of Lyft and Uber drivers is opting into an easy, and sometimes-intended-to-be-temporary, dead-end career path. This may be ok at the moment for some drivers who enjoy driving and the flexibility of the job. But driving as an occupation will disappear practically overnight when self-driving cars hit the road. Similarly, 99designs Tasks has a web interface for the customer to explain a simple and quick design task, plus an API to dispatch a visual designer to complete the task. At Segment we’ve actually built a 99designs Tasks API</a> to create vector logos from an image url: 99designs.logo(card, url); // pseudocode ;)</code></pre>What’s bizarre here is that these lines of code directly control real humans. The Uber API dispatches a human to drive from point A to point B. And the 99designs Tasks API dispatches a human to convert an image into a vector logo (black, white and color). Humans are on the verge of becoming literal cogs in a machine, completely anonymized behind an API. And the companies that control those APIs have strong incentives to drive down the cost of executing those API methods. In the long run there’s always something for people to work on and improve, but the introduction of this software layer makes we worry about mid-term employment 5-20 years out. Drivers are opting into a dichotomous workforce: the worker bees below the software layer have no opportunity for on-the-job training that advances their career, and compassionate social connections don’t pierce the software layer either. The skills they develop in driving are not an investment in their future. Once you introduce the software layer between “management” (Uber’s full-time employees building the app and computer systems) and the human workers below the software layer (Uber’s drivers, Instacart’s delivery people), there’s no obvious path upwards. In fact, there’s a massive gap and no systems in place to bridge it.And I suspect these software layers will only get thicker. Entrepreneurial software developers will find ways to tie these APIs together, delivering products that combine several “human” APIs. Someone could use Mechanical Turk’s API to automate sales prospect research, plug that data into 99designs Tasks’ API to prepare customized infographics for the prospect sent via email. Or someone could use Redfin’s API to automatically purchase houses, and send a Zirtual assistant instructions via email on how to project-manage a renovation, flipping the house completely programmatically. These “real-world APIs” allow complex programs (or an AI in the spooky storyline here), to affect and control things in the real-world. It does seem apropos that we invest in AI safety</a> now. As the software layer gets thicker, the gap between Below the API jobs and Above the API jobs widens. And economic incentives will push Above the API engineers to automate the jobs Below the API: self-driving cars and drone delivery are certainly on the way. The gap in training and social groups above and below could mean that new automation technology causes sudden, large-scale unemployment and a surge in demand for subsidized training. I hope we’re ready. Milestones for SaaS Companies 2015-01-28T00:47:07.000Z When you know your next milestone, you can focus on it. But between product market fit and profitability most startups will only hear the mantra: “grow! grow! grow!” Yes, of course. But for venture capital funded companies, product market fit and profitability are often separated by 5-7 years, 100x team growth, and multiple funding rounds. What are the milestones in between?Beyond our advisors and investors at Segment</a>, I’ve only found one great resource on how to scale a SaaS business: SaaStr</a>. He offers some poetic elegance on three major milestones: “Getting from $0-1m is impossible. Getting from $1-10m is unlikely. And getting from $10-100m is inevitable.”—Jason Lemkin, ex-CEO of Echosign</blockquote> Each of those revenue milestones is definitely an achievement. But in our experience at Segment we think about six major milestones, and they’re not exactly based on revenue numbers. Each milestone below is a key turning point in the business and indicates a moment to re-evaluate our priorities. 1. Product Market Fit</h2>How you know: people will stick around and share your product. You’ll see high month-over-month retention (95%+), and word of mouth growth (the majority of signups are direct traffic).You’ve solved a #notimaginary problem for people. Huzzah! But honestly this is a pretty squishy milestone. We built stuff for 1.5 years before finding product market fit, and then it was pretty dang obvious. But be careful, because you can lose product market fit even after you find it</a>! 2. Paying Customers</h2>How you know: 10 paying customers who aren’t your friends.Woot! You’ve created value for people in a way you can capture</a>. Free-to-1¢ is a big gap</a>. Luckily, your marketing reach definitely sucks at this point so your market penetration has to be tiny. You can definitely find another 100 customers out there somewhere. YC always told us that once you have 10 customers, you can find 100, and if you can find 100, you can definitely find 1000…. keep rollin’. 3. Statistical Significance</h2>How you know: hundreds of paying customers. You can finally estimate unit economics for marketing, sales, support and servers. You have enough data about price and market segments to build a reasonable, bottoms-up estimate of market size. This is probably around $1m ARR, aka “the impossible” according Saastr.4. Capital-Efficient Growth</h2>How you know: for every $1 burnt you add $1 in ARR.This means that if your bank cash balance falls $2m in Q1, you need to be adding $2m in ARR. It’s a measure of capital efficiency</a>. As you become more capital efficient on the path to Cash Flow Positive, you’ll add more and more ARR for every $1 you burn. Yessss! You’re able to efficiently invest money to grow the business, which is appealing to investors, because when they invest $5m you can generate a $5m recurring revenue stream. You can’t really celebrate though: you’re still dependent on outside capital to grow. This milestone is probably around $3-6m ARR, pushing towards “unlikely” in SaaStr’s words. However, some companies</a> may choose to stay at this stage for a long time, especially in a competitive market where they believe winner takes all. It’s not uncommon to continue selling equity for cash, and spend it to grow aggressively through $100m ARR or more. 5. Cash Flow Positive</h2>How you know: your cash balance is rising, but net income is still negative.This is the first, fleeting feeling of freedom from outside capital. When a customer commits to annual prepay you get a surge in cash balance, but then nothing for the next 11 months. As long as you keep closing new deals, your deposits each month can exceed your spending. Glorious. But keep selling.</a> And keep some cash buffer in case growth takes a hit. 6. Profitable</h2>How you know: your cash balance is rising, and net income is positive. Freedom from outside capital. Cash balance is growing, even without new business. The promised land. The Impact of Self Driving Cars 2014-12-29T00:50:53.000Z The average American drives for 101 minutes</a> a day. That’s 10% of waking life. Driving. Even our neighborhoods and cities are constructed around the needs of cars. Suburbia is the most obvious example, created in the 1950s as a direct result of the car</a>. Cars are so pervasive in America that it’s difficult to comprehend the full impact of eliminating driving. Here are a few predictions to get you started. Travel will be different.</h2></figure>Road trips today are stressful. It’s the end of a long week, are you really going to hop in the car and drive 5 hours to your family? Or to go skiing in Tahoe? The fantasy of escape and the wide open road is alluring, but the reality is a long, droning, half-focused exhaustion on the interstate that feels a bit more like punishment. But the first thing I’ll be doing with a self-driving car is a weekend road trip. Because it’ll be completely different.Friday night we’ll snuggle up in the car, watch a movie, eat dinner, get a solid night’s sleep, and wake up at the Grand Canyon ready for a day of hiking. And instead of camping or staying at a hotel, we’ll sleep in the car as it drives us up to Park City for some Sunday skiing. Sunday night we’ll sleep in the car again on the way back to San Francisco, arriving in time for work on Monday morning. Here’s the itinerary</a>, just waiting for the car! The incredible simplicity of self-driven roadtrips will probably be the final straw in destroying regional airlines. “Last leg” regional flights have already become surprisingly expensive</a> due to the high cost of jet fuel</a> and reasonable expectations for pilot wages</a>. When you can do the whole trip or even the last leg of your flight in the comfortable privacy of your own car, regional airlines are just toast. But “your own car” may be a bit of a misnomer as well. The future of personal vehicles will probably look a lot more like Uber (a “fleet”) rather than individually owned cars. And, getting a bit more sci-fi… the operational efficiency of a fleet might improve revenue-per-vehicle enough to justify spending a lot more per vehicle. If we could squeeze 10x usage-per-vehicle out of operational fleet efficiency, then we could all be riding in $300,000 cars. That’s the initial price of Terrafugia’s flying cars</a>. We’ll travel more. Probably a lot more. But the market for short weekend flights will probably collapse, to be replaced by flying cars? Finally?</li> We won’t use roadside hotels. Sleeping while moving is way better. Resorts will do fine though.</li></ul> Family operations will become simple.</h2></figure>British moms spend an average ~7 hours per week driving their kids around</a>. To soccer practice. To a friend’s house. To summer camp. But with self-driving cars that disappears, even for families with lots of kids. The car can take care of it. And kids and parents will both love it, because it’s pure flexibility and freedom. Female labor participation rates in the US have been dropping since 2000</a>, but the sudden elimination of a whole class of mid-day driving chores could make it easier for child caretakers (almost entirely women in the US) to return to work. For the kids, I know when I turned 16 and got my license it was a magnificent, freeing moment. With self-driving cars that moment won’t go away. In fact it’ll happen younger, because “getting a ride to Y” will just require permission, not a tired parent’s “sigh, no I already drove you to X today.” But how much younger? A five-year-old alone in a car seems unlikely? But by age 12 the kid is definitely fine by themselves. What kinds of permissioning will we need? Per-trip approval? The kid with full permissions is going to be popular indeed! And don’t forget about grandpa and grandma. The moment when an elderly person loses their license can be devastating, humiliating and depressing</a>. There are 8.4m elderly people who depend on others for rides</a>, and 15.5m elderly who have no good public transportation options</a>. Another 78 million boomers are on their way to driverless age as well. But with self-driving cars they’ll be free to roam. Kids will have more freedom. Unique after-school programs could blossom.</li> Parents will drive less, freeing up tens of millions of hours in the US. More moms will probably return to work.</li> Grandma is on the road again. Getting older won’t mean being trapped in the old-people’s home.</li></ul> There must be other demographics I’ve overlooked here too. The trucking industry will be remade.</h2></figure>There are 3.5 million truck drivers in the US</a>, or about 3.4% of the adult workforce. Self-driving trucks will eliminate almost all of those jobs… driving hazmat trucks may survive the longest. The unemployment will certainly sting in the short term as truck drivers look and train for new jobs. But the secondary effects will also be interesting. In the US there are, very roughly, 3 million hotel rooms rented per night</a>. If you take ~1 million long-haul truck drivers off the road, roadside motels are going to see a significant hit, even if many of them have bunks in their trucks. Roadside fast-food restaurants and gas station delis will also take a hit. Driving trucks is high pressure, stressful and demands long hours behind the wheel. So it’s not surprising that roughly 30% of drivers use illegal amphetamines</a>. That means ~0.3m long-haul drivers are using amphetamines to stay focused and awake. Since there are 3m amphetamine users in the US, and about 0.3m amphetamine addicts</a>, it’s possible that self-driving trucks could really take the wind out of the amphetamine market in the US. Since long-haul truck drivers spend so much time away from home, it seemed possible that long-haul driving could be a significant source of demand for sex workers. There is an industry of prostitution</a> at truck stops</a>, but it turns out that the vast majority of prostitution clientele aren’t passing through, they’re local</a>. Even though it’s not a significant part of the overall prostitution market, truck stops are known to be a particularly strong distribution network for drugs and STDs. So even though a small percentage of drivers are involved, eliminating drivers from long-haul trucking may slow the spread of AIDS and other STDs. But it could be more than offset by increases in personal travel. On the political front, the Teamsters Union</a> is one of biggest and most powerful unions in America, with most of it’s members working jobs in trucking, chaffeuring and delivery. In recent years the Teamsters have shifted their allegiance from the Republicans to the Democrats, and donate roughly $25m to campaigns each year. But the end of driving-related jobs will likely drain most of the Teamsters’ million-strong membership. And with members goes money and influence in the American political system. Roadside fast-food joints and motels will dwindle.</li> The amphetamine market will shrink significantly.</li> The Teamsters Union will lose most of it’s power.</li></ul> The effect on individual drivers in the trucking, chaffeuring and delivery industries will be painful to watch unfold. For better or worse it’ll be a fascinating study in economics, technology and job dynamics. I just hope we can build the education systems to handle millions of displaced drivers who’ll need training for new jobs. But at a personal level I’m stoked for easier private travel and almost magical family transportation. Still, it’s difficult to fully grasp what changes are coming… the end of drunk driving, good transportation for disabled folks, the loss of 750,000 bus driving jobs, automated fast food delivery, a complete overhaul of the USPS, the end of the DMV</a>… I’ll stop now. MVP Doesn't Mean Anything 2014-02-25T01:09:59.000Z “Minimum Viable Product” has always confused me. What the hell does viable mean? Is an idea “viable” when someone says they like it? Tweet it? Sign up for it? Use it? Pay for it? It’s so unclear that “MVP” has become a buzzword. The problem is that a product can only be “viable” in retrospect. You can’t know it’s viable until you’ve launched it, had people use it, gathered their feedback… maybe even grown a successful company out of it. To prove viability takes time, at least enough to ride out the launch spike and valley of death. It could take weeks, months or years to really prove viability. But “viable” isn’t just a misguided name, it also has a serious effect on the people launching it. First, people strive to make a “viable” product before launching. This is the exact opposite of it’s intention. The whole idea is to launch early and test the market. In trying to build a “viable” product straight away, they have the perfect excuse to delay and delay. Don’t launch a viable product, launch a test. Second, launching a product with the “viable” label creates a hindering psychological barrier to the idea that it’s a test and you’ll likely need to pivot.Segment.io</a>’s history is actually perfect illustration of the difference between launching something testable, and the longer term search for viability. The first “test” for Segment.io wasn’t a product at all. It was a souped-up for loop with a nice API called analytics.js</a>. It could send data to four different analytics tools. At the time, I disagreed vehemently that we could build a business around it, and since it felt like a distraction I wanted to kill the idea as fast as possible. So I convinced the other guys to submit the open-source repo to Hacker News, thinking it would just get quietly ignored into oblivion. Quite the opposite. The repo went straight to the top of HN and gathered over a thousand stars on Github in the first day. It was a fantastic test. My doubts were removed immediately. The interest on HN and Github clearly showed there was a market, and PG’s advice was “Try it out for a month. Can’t hurt.” So we did. In January 2013 we launched a hosted version that drew several thousand signups. A bunch of those early signups became active users. A few weeks later we released server-side libraries and support for more integrations. In June we launched mobile libraries. In the second half of the year we closed our first enterprise contracts and the team</a> grew from 4 to 11. Throughout the year our userbase and monthly revenue grew consistently. After not understanding it initially, I’m now Segment.io’s biggest fan. We have an opportunity to build a great company and a product that changes the analytics market considerably. But when exactly did the product become “viable”? I don’t know. And it doesn’t really matter. The definition of viability seems to be a moving target that started with “does anyone use it?” and has now ratcheted up to “is it profitable?” Viability is always the goal, but on the road to viability, testability is much more important. Analytics.js was testable, the first version of hosted Segment.io</a> was testable, and every product change since then has been testable. Being testable is actually useful. So stop calling them Minimum Viable Products. They are Minimum Testable Products. Online Education's Dirty Secret — Awful Retention 2013-04-01T00:20:57.000Z I’m extremely excited about online education, but I’ve noticed that online education products have a really serious problem: low retention. I’ve used Coursera, EdX, Hack Design, Duolingo, Codecademy… and I’ve churned from all of them. I bet you did too! I don’t want to tear down these products or the people who’ve built them, I’m rooting for them all the way. They just need some tough love, and so this article explains why I churned: the starting commitment is too high, the re-engagement emails are terrible, and the pacing is impersonal.How low IS their retention?</h2>Coursera founder Daphne Koller said last year that only 7-9%</a> of students who sign up actually “finish” the class. The definition of finish is a bit fuzzy, so I wanted to collect some more data. The Coursera class Introduction to Operations Management had 87,000 people sign up, but only 4,360 views</a> on the final lecture. This is a 5% retention rate for viewership, and presumably worse for the assignments. Probabalistic Graphical Models taught by Daphne Koller herself signed up well over 35,000 people (announced a while before the class started, via email). In week 4 there were 433 posts about the homework, week 6 there were 316 and by week 8 only 275 posts (hand-counted in the class forums). Even if you assume 10x as many people completed the course as posted in the forum, that’s about 6% retention rate. Introduction to Algorithms Design and Analysis Part I got 10,000 likes, tweets and +1s</a>. Presumably at least that many people signed up for the course. But the first video in the course got only 2,500 views and later videos got about 500 views</a>. Showing a maximum retention rate of about 5%. So the data from Coursera shows about a 5% retention rate from Class Sign Up to Class Completed. If you’ve signed up for one of their super-popular classes with “80,000 students!” then you were almost certainly one of the ~76,000 that did not finish the class. We could come up with a bunch of excuses about why online education will always have worse retention, or we could figure out ways to fix it. How can we fix it?</h2>Coursera and EdX do have amazing content from top-notch professors at the world’s best universities. That’s why 3+ million people have signed up for Coursera and EdX classes. But my favorite teachers didn’t just have great content, they also had great content delivery. They made the content fun. Gripping even. And thats where Coursera and EdX have let me down. I think Coursera and EdX can learn a lot from three other online education products: Codecademy, Hack Design and Duolingo. These three online education products have each impressed me with their delivery of content, for three different reasons.Codecademy asks for no commitment.</h3>They completely eliminated the starting level of commitment: you arrive at the site and started learning javascript. No signup, no complex reading or video lectures, no commitment whatsoever. You just start following simple instructions. Of course you slowly escalate to harder and more compelling material, increasing your commitment every step of the way.</figure>And boy has that worked! They’ve gotten 75,000 tweets and millions of users. It’s been hailed as the future of programming education and is seeing adoption at schools around the world.Hack Design has amazing emails.</h3>They nailed email re-engagement. Since they’re a weekly email course about web design, they’ve put a lot of thought into the structure and copy of their emails. They use beautiful images and similar visual structure every week so that I know exactly where to click and what to do. Here’s an example email with with huge, enticing links to the newest content.</figure>The beauty is that every week I get an email that motivates me to learn more about design, and makes it incredibly easy to get started again. I just click some links and start reading.And Duolingo has perfect pacing.</h3>Duolingo teaches you a new foreign langauge, through a series of automated question-answer exercises. I’m learning German and my wife is learning Italian. And WOW has their gamification sucked me in and made me competitive. My wife and I regularly compete to get more points on Duolingo:</figure>You can see in this screenshot she’s got more points than me! (She kindly reminded me of this fact while proof-reading this article.) I need to get my German game back on! Coursera and EdX have disappointed me on all three fronts.</h2>They ask for huge time commitments right at the beginning. The re-engagement emails are de-motivational and full of administrative details. And the classes move way too fast unless you’re a full-time student. I’ve put together some screenshots to show you what I mean.You must commit to the class.</h3>The “Class is starting” announcement from EdX says “stay current with the material. Don’t fall behind.” which is a nice bit of positive reinforcement. Yes sir! And apparently I need to do something every couple days. Not sure what yet, but ok! The email is incredibly demanding, and gives me nothing to be excited about. What is the class about again? And where’s the link?</figure>Oh boy this sounds like a lot of work, and I’m not even sure how to start. Definitely not happening this week, we just launched Segment.io</a>! The structure they’re trying to impose is a throwback to how real universities operate. You pay a ton of money up front, move across the country, leave your family behind… it’s a huge commitment! But that’s not how online works. Online you have to suck people in like Codecademy. Inch by inch you get them more engaged and more committed. Awful re-engagement emails.</h3>Then in week two of the class I get an unmotivational email saying that “this week’s [stuff] is available.” What are we covering this week? Anything interesting? And where’s the bloody link?? </figure>Are you serious? Look at this gorgeous video email I get from Wistia: </figure>This class is too fast for real people.</h3>Then in week three of the class I get an email telling me to join a Google Hangout, watch 6 videos, do the in-video questions, read the notes, do two problem sets, and prepare for an upcoming exam. </figure>Let me clarify: I want to learn human physiology, but I work at a startup. I’m completely lost in this artificially-imposed schedule. There is no point in trying any more. Forget it. The content available on Coursera and EdX is amazing.</h2>The problem is that I need help to stay motivated and engaged. Coursera and EdX must figure this out… otherwise they’ll just keep losing 95% of their students. I’m very worried that they don’t understand this. Here’s what Daphne Koller, founder of Coursera, said in November: “Many of these students never really intended to seriously take the class in the first place.”</blockquote> I did intend to take Introductory Human Physiology and Data Analysis. Stop blaming your users and instead say “Wow, so many people want to learn. How can we help them stay motivated and engaged? Let’s help them achieve their dreams.” Edit: I’ve heard from EdX that they’re thinking about this :) Very excited for the improvements!</aside> radioactive.js 2013-03-11T00:38:23.000Z One of the biggest problems I’ve encountered in writing</a> about nuclear reactors</a> is that people don’t understand radioactive decay. This is a huge problem because it means that 99% of the population is totally unqualified to decide anything about nuclear energy. It’s conceivable that some form of nuclear energy could solve both global warming and energy demand simultaneously. That’s a really big deal, so rather than just panicking to the latest alarmist trend, we need to make a really informed decision. Since we’re a democracy, we need everybody to understand how nuclear works. To help teachers, developers and journalists spread that understanding, I’m open sourcing radioactive.js</a> on Github. As a start, check your own understanding with this Darwinist test: Suppose I have 1 kg of Cesium-134, with a half-life of 30 years. And 1 kg of Uranium-238, with a half-life of 4.5 billion years. I’m going to give you one of the blocks, and you have to sleep with it tonight like a teddy bear. Which one do you want?</blockquote> If you guessed Cesium-134, you’re dead. If you chose the block of Uranium-238, you’ll be just fine. You want the Uranium-238 because its long half-life means that it decays slowly. Short half-life isotopes like Cesium-134 decay so quickly that you get a lethal dose of radiation super fast. In this plot produced by radioactive.js, you can see that the cesium block is over a million times more radioactive than the uranium block (the scale is logarithmic): </figure>The importance of radioactive.js is that it lets us visualize the problem, which significantly expands the audience that can understand what’s going on.What else can we learn by visualizing radioactive decay?</h2>First, you’ll quickly discover that radioactive waste comes in three flavors based on the half-life of the material:Short half-life, extremely radioactive materials like Cesium-134 are super dangerous to handle, but decay quickly to background levels. We know how to build structures to hold this waste until it’s safe. </li> Medium half-life, highly radioactive materials like Americium and Plutonium are also dangerous to handle, but still take thousands of years to decay to background levels. We literally don’t know how to build structures capable of storing high-level radioactive waste like this for soooooo long. The ancient Egyptian pyramids haven’t even lasted this long. This type of waste is mostly composed of “actinides”.</li>Long half-life, barely radioactive materials like Uranium-238 and Thorium-231 are actually quite safe to handle, and take billions of years to decay to background levels. Obviously we have no idea how to build structures to store this stuff, but these isotopes are common in standard soil all around the world.</li></ol> On a logarithmic plot these three types of radioactive waste have distinctly different profiles:</figure>Different decay profiles, different disposal.</h2>Each type of waste needs to be disposed of differently, with wildly different disposal costs. Looking at the plot, it’s easy to see why! Some of the waste is gone in 100 years, some if it won’t be gone for hundreds of thousands of years, and some won’t be gone for billions of years! Each type will need drastically different methods for disposal.But waste is never discussed that way… instead, it’s all bundled into one Big Scary Monster. The result is that the public</a> has an unending political</a> discourse</a> about the dangers of nuclear waste that never gets anywhere. It usually goes something like this: Person 1: “Our brand new nuclear plant design produces three times less waste.” Person 2: “But the waste it produces lasts for thousands and thousands of years!” This chatter is terribly confused and useless, but it’s the reality of the discussion. Nuclear waste is not all produced equal. It makes no sense to talk about “three times less waste” unless you talk about the exact profile of the waste. The debate should go like this: Better Person 1: “Our New Nuclear Plant [green] design produces three times less waste. Let me show you how the radiation from its waste is lower than waste radiation from Current Reactors.” </figure>Better Person 2: “That’s not a very impressive difference. The actinide waste (second bump) produced by your design lasts for thousands of years, and it’s difficult to dispose of. Let me show you our Alternative Nuclear Plant [bright green] design that produces dramatically less actinide waste.”</figure>Now that we’ve compactly visualized the options it’s possible for a non-nuclear-engineer to discuss the situation quite intelligently.That’s why I built radioactive.js</h2>It’s an open source javascript library that models radioactive decay. “But that’s easy!” you say, “It’s just an exponential function.”</figure>Not so fast. Radioactive decay of real nuclear waste is significantly more interesting.As radioactive atoms decay, they transform into other atoms that are also radioactive, which in turn decay again! It’s a chain.</a> For example, Plutonium-239 decays into Uranium-235, then Thorium-231 and then through 9 other isotopes before finally becoming Lead-207. Each decay in the chain releases radiation, and when we model real nuclear waste we have to branch out and model the entire decay chain. Secondly, real waste from nuclear reactors is composed of lots of different isotopes. A simple waste model for your standard Pressurized Water Reactor could easily start with 14+ radioactive isotopes. How radioactive is that after 1,000 years?? So radioactive.js models the complete decay chain, and it will model an arbitrary spread of “input” isotopes. For example, it can model the radioactivity produced by waste from a standard Pressurized Water Reactor: </figure>The library is open-source. Here are some good starting points:The isotope data used to do the modeling is in isotope-data</a></li> The decay chain extraction is done on radioactive-decay:68</a></li> The underlying math</a> is reflected in the code at radioactive-decay:114-174</a></li></ol> I’d love to have your help in building radioactive.js into a tool for better teaching and communicating about nuclear energy. I hope that radioactive.js will help cast new light on the otherwise un-ending nuclear debate, and help create a discussion about the aspects that really matter. An honest, informed discourse about nuclear tech is critical for our future. If you build something with radioactive.js, let me know @reinpk</a>! Gravitational Lensing to Observe Ancient Earth 2013-03-04T01:41:55.000Z I was at SFMOMA with Erika a few weekends ago and we saw an exhibit showing the work of Lebbeus Woods – a futuristic architect and illustrator.</figure>A quote at the beginning of the exhibit caught me off guard… I had never really thought about light this way:I dearly love the form of things. Particularly because forms make light visible, and light is a sublime substance. We only see light when it is reflected from the surfaces of forms and the diverse materials of which they are made. It is not only that light pervades the universe and is a kind of messenger of the histories and mysteries of time and space....- Lebbeus Woods</blockquote> This thought stuck with me: the whole history of Earth and Mankind is still out there in the universe, streaming away in an expanding sphere of light. What if we could get out there somewhere and see that light? It would be like time travel with read-only access. As I walked around the rest of the exhibit I started to get a crazy thought… 6,000 years ago, our ancestors were wandering around the globe with pointy little spears. And, just like every day since, the Sun was shining and light was reflecting off their heads, back into space. Over the next 3,000 years that light zipped off into the galaxy, never to be seen again. But suppose a tiny portion of that light was headed right for a black hole. And then suppose a tiny portion of that tiny portion of light encountered the black hole at just the right angle so that it wasn’t sucked away forever. But instead, got bent exactly 180 degrees, boomeranged around the black hole and headed straight back to Earth. After the second 3,000 year leg of its journey, that light is streaming back through your window. The idea is tantalizing to me – that by staring at a black hole we could literally look back in time. I couldn’t put it to rest, so I dug through some physics literature and pieced together just how (in)feasible this observation would be. It turns out it’s possible. Almost.Gravitational Lensing</h2>According to Einstein’s Theory of General Relativity, light is affected by massive objects because they curve spacetime. We don’t need to understand the physics deeply. The point is that massive objects like black holes and galaxies can bend light significantly:</figure>This is picture a of Einstein’s Cross, a distant “Quasar” repeated four times, gravitationally lensed around the galaxy in between us and the Quasar.But just how far does the light bend? For low deflection angles the calculation is straight forward, but we’re interested in light that’s practically grazing the surface of the black hole. These higher deflection angles are extremely complicated to calculate, but Valerio Bozza put it together in 2007</a>: </figure>Below the asymptote on that plot is where light gets sucked into the black hole and is never seen again. But we don’t want that, we want the light to be completely reflected. To be reflected, so that we could see ancient Earth in the black hole, we’d need a deflection of 180 degrees, or pi radians. Looking at the graph you can see that this “reflection” happens near the asymptotic “edge” of the black hole.But then there’s noise.</h2>The biggest black holes sit at the center of galaxies and have masses millions of times bigger than our Sun.These seem like perfect candidates for observing our “reflection” but there’s a glaring problem. Around these huge black holes there’s an accretion disk</a> of gas, with stars colliding and exploding everywhere. This creates a huge amount of light that would drown out any “reflection” of ancient Earth. If you take a look at Sagittarius A*, the black hole at the center of our own galaxy, you’ll see what I mean. We could never spot ourselves in the middle of this: </figure>What we need is a nice, simple black hole that’s minding it’s own business in a quiet neighborhood.We’re looking for a MACHO.</h2>MACHO</a> is a whimsical name for “dark” massive objects. It includes black holes that don’t have big messy accretion disks. The only way we can detect a MACHO is when it moves between us and a distant galaxy, creating a “gravitational lensing event” where the brightness of the distant object suddenly increases and decreases: </figure>These MACHOs are much better candidates for our attempt to observe a “reflection” of the Earth or our Sun. The best candidate so far is a black hole named MACHO-96-BLG-5</a>, which was observed at a distance of about 3,000 light years from Earth. It’s “best” because it’s the closest one we’ve ever seen, and closer means the “reflection” of ancient Earth would be brighter. Could we see ourselves in MACHO-96-BLG-5?</h2>In 2002 Daniel Holz and John Wheeler investigated this idea and ran all the calculations in their paper Retro-MACHOs: Pi in the Sky?</a> The short answer is no, not with current telescopes. The problem is that even the “reflection” of the Sun is far too dim. Holz and Wheeler ran the calculations for hypothetical black holes that might wander within a couple light-years of Earth. Under those unlikely circumstances, observing the reflection is doable with existing telescopes, or on the brink of doable with telescopes being planned. Here’s their results for black holes (BH) with 1 or 10 times the mass of the sun, within 1 parsec (3.24 light-years) of Earth: </figure>To help you understand the magnitude scale: a higher positive magnitude is dimmer. The Sun at noon is magnitude -27. The full Moon is -13.</a> The Hubble Space Telescope has detected stars with a magnitude of just 30. As you can see in the table, Hubble might just barely be able to observe the reflection in some (improbable) cases. Their results are for MACHOs we might observe, but for MACHO-96-BLG-5 they simply say there’s no way we could observe the Sun in the “reflection”… which means the magnitude must be 50 or higher. Extremely dim. So we need a better telescope.</h2>The light-gathering capacity of a telescope is limited by the surface area of its mirrors. The Hubble has a collecting area of 4.5 square meters and a diameter of 2.4 meters.In order to observe a magnitude 40 observation like the one in the table above, we’d need a 240 meter diameter telescope. For a magnitude 50 observation, we’d need a 24 kilometer diameter telescope. The largest telescopes currently under consideration are the European Extremely Large Telescope</a> or the even more hilarious Overwhelmingly Large Telescope</a> with diameters of 40 meters and 100 meters each. So even though occasional photons from 6,000 year-old ancient Earth are coming back through your window, it’ll be a while before we can see them. Maybe there’s a better MACHO?</h2>The hunt for more MACHOs is still on. And there’s good hope that we’ll find one significantly closer than 96-BLG-5.According to research published in 2002</a> the expected density of MACHO black holes in the vicinity of the Sun suggests that there’s probably a MACHO within 10 parsecs (32.4 light-years) of Earth. Of course, then you’d only be looking back at an “ancient Earth” from 65 years ago. Until then, let’s figure out how to build bigger space telescopes :) Thorium Reactors 2013-01-15T00:42:35.000Z My last article about thorium</a> as an alternative nuclear reactor fuel drew way more readers than I expected. I intentionally glossed over the complexities of specific reactor designs for the sake of simplicity, but in this article I want to go deeper. This article explains some of the differences between traditional uranium reactors and molten salt thorium reactors (MSRs). Traditional uranium reactors are by far the most common type of reactor around the world. This includes all 359 Light Water Reactors and 31 Heavy Water Reactors in operation today. These reactors use a solid uranium fuel loaded into fuel rods, moderated by water. Molten Salt Reactors (MSRs) were selected in 2002 as one of six future “Generation IV” reactor designs. They were researched heavily in the 1950s and 60s at Oak Ridge National Laboratory</a>. The results of the experiments were considered extremely promising, but the competing Liquid Metal Fast Breeder reactor design won out politically for follow-up funding in 1970, and the MSR program was canceled. [</a>NSE</a>] So, why should we care about this practically forgotten molten salt reactor? Well, because (1) the claims about these reactors turn heads: “they can safely power all of human civilization for millenia without significant waste” [</a>Sorenson</a>], and (2) there is a body of research to support these claims, with active research programs in China and Japan, and a retired program in the US. You have to wonder what’s stopping us from tapping this supposed panacea of energy, and a dose of skepticism for these claims can only be healthy. What are the technical difficulties? To find out, we need to compare traditional uranium reactors and molten salt reactors in two of the most cost-sensitive areas: safety and waste. Safety: Avoiding Meltdown</h2>Our main safety goal is to avoid nuclear core meltdown or other damage to the reactor core that can release radioactive materials into the environment. The three most infamous core meltdowns are Three Mile Island</a> (USA 1979), Chernobyl</a> (USSR 1986) and Fukushima I</a> (Japan 2011). All three were traditional uranium reactors – what caused their failure? In traditional uranium reactors, uranium fuel pellets clad in zirconium are loaded into fuel rods, and many fuel rods are loaded into the reactor core. Diagram of fuel pellets, assembled fuel rods, and reactor vessel in a CANDU pressurized heavy water reactor; courtesy of AECL.</figcaption></figure>If the reactor temperature isn’t carefully controlled, any of these components can melt: the fuel rods, zirconium pellet cladding, or the uranium itself. This screws up the structure of the core, and makes it even harder to control. This can lead to total disaster if not carefully managed by humans. In most modern reactors, the core is shut down by control rods in 3-5 seconds (fission stops), but the core still contains lots of highly-radioactive fission products, and the decay heat from these products requires continuous cooling for weeks even after core shutdown. That cooling process also must be human managed and actively powered.At Fukushima a tsunami wiped out all the power generators simultaneously, so all the cooling systems failed in parallel. The operators decided to delay a critical backup cooling option – to flood the core with seawater – until it was already too late. [wiki]</a> At Three Mile Island the operators hadn’t been properly trained. So when a valve got stuck open, they responded incorrectly, causing a loss of coolant and a partial core meltdown. [wiki]</a> At Chernobyl a complex “xenon transient” was mismanaged while the reactor was being restarted, leading to a complete meltdown and the disaster it’s famous for. When uranium atoms fission in the core of the reactor, xenon-135 is one of the most common products. Xenon-135 is an extremely strong “neutron poison”, meaning it slows down the nuclear reaction. This would seem great, BUT if you try to force a reactor full of xenon-135 to start up quickly (Chernobyl) you have to adjust the control rods oh-so-carefully to prevent a meltdown. [wiki]</a> Worse yet, secondary explosions in traditional reactors can come from the pressurized steam/water that cools the core. Or hydrogen gas produced by water reacting with the zirconium fuel pellet cladding. [wiki]</a>, [wiki]</a> Nuclear reactors are operated under extremely stringent requirements, and the above examples in no way show that civilian nuclear reactors are a bad idea or are mismanaged. The main point is that careful human management and tending of traditional uranium reactors is required in order to prevent a nuclear meltdown. Only in unusual circumstances do they fail. But, they do fail. So what about Molten Salt Reactors?</h3>In a Molten Salt Reactor the reactor vessel is full of molten sodium fluoride (the active ingredient in toothpaste & drinking water) or similar salts at about 800-1000°C. You dissolve your thorium or uranium fuel into this liquid. [DOE]</a> Diagram of a molten salt reactor courtesy of the US DOE Generation IV Roadmap</a>.</figcaption></figure>During the four-year operation of the Molten Salt Reactor Experiment at Oak Ridge, they discovered that the MSR had intrinsic protections against many of the common failure modes in traditional uranium reactors:The catch-all failure protection was a “freeze plug”. At the bottom of the reactor vessel they connected a pipe running down to several drain tanks. An actively powered cooling system kept the molten salt frozen solid in the pipe. Should power fail like at Fukushima, or the core of the reactor get too hot like at Chernobyl or Three Mile Island, the freeze plug would melt and the fuel-carrying molten salt would drain into passively cooled drain tanks. In other words, the meltdown crisis is inherently averted by the physics of the situation, not heat-of-the-moment human control. [Benes]</a> The team at Oak Ridge also discovered that they could continuously re-process the molten salt to remove fission products like xenon-135, preventing complex transients like at Chernobyl. Even better, they discovered that the molten salt in the core of the reactor had a very high boiling point (around 1400-1700°C) which meant that the molten salt would be much less likely to enter a gaseous state during a crisis. Without a gaseous state, the reactor vessel wouldn’t reach high pressure even if the freeze plug failed to melt, so you wouldn’t see secondary explosions either. So in all the research done so far, MSRs appear to have intrinsic safety features, which is highly desirable. But I still felt unsatisfied with all this positiveness and no sign of problems, so I dug a bit deeper and eventually found some talk about the main technical challenges with molten salt reactors encountered by the Molten Salt Reactor Experiment (MSRE) in the 1960s. [Benes]</a> Here they are: The reactor vessel on the MSRE was made of Hastelloy-N, an advanced nickel alloy designed specifically for use with molten fluoride salts. But over the course of several years it became apparent that the alloy was being chemically eroded by (a) chromium leaching from the Hastelloy-N into the molten salt, and (b) tellurium (a fission product) causing embrittlement in the Hastelloy-N reactor vessel walls.</li> The graphite moderator, used to slow neutrons down to “thermal speeds” in the core, had severe swelling and radiation damage after four years.</li> Tritium (a radioactive isotope of hydrogen) was discovered in the secondary coolant loop. In a larger reactor this would pose a radioactive release concern.</li></ol> But just as quickly, the team at Oak Ridge seems to have thought of, and in some cases implemented, solutions to these problems: They discovered that slight adjustments to the chemistry of the molten salt (adding beryllium) would prevent the tellurium-cracking and chromium-leaching. Alternatively, newer research has shown that adding a small amount of niobium or titanium to the Hastelloy-N metal can also prevent both issues.</li> The graphite moderator can be replaced every four years. Or, much more compelling, the concentration of thorium/uranium/plutonium/actinide fuel can be adjusted to make the MSR a “fast neutron reactor” that doesn’t need the graphite moderator at all.</li> If the primary coolant loop runs on a second molten salt, its chemistry can be made to absorb tritium, preventing the tritium from ever reaching the environment.</li></ol> So to be quite honest, the original MSRE team at Oak Ridge seems to have figured out the real problems, fixed them, and operated their reactor quite successfully for four years before funding was cut. They even built and validated the freeze plug + drain tanks, and the xenon-135 removal process. Of course there are problems that can’t be foreseen when put into production with hundreds of reactors, but these main issues are (happily) already resolved. Great, what about Radioactive Waste?</h2>Radioactive waste comes in several different forms, and each is handled differently. Uranium fuel gets fissioned in the core, but in a traditional uranium reactor 98% or more is left unburned. The remaining fuel is very long-lived, in the millions or billions of years, and is therefore only slightly radioactive. Fission products like cesium-137, strontium-90 have much smaller nuclei and are much less stable. They all have half lives less than 90 years, and are intensely radioactive.Actinides like plutonium, americium and neptunium are produced as an undesired by-product. While most of the fuel follows the desired “clean” fuel cycle, the neutrons flying around in the core of the reactor are effectively random, and some fuel or intermediary isotopes can occasionally absorb an extra neutron or two. This causes a small percentage of the fuel to leave the desired fuel cycle, producing a class of waste called the actinides. These are heavy, unstable isotopes with half-lifes in the 100s and 1000s of years, and they pose a real problem for waste disposal since they are not short lived but are still highly radioactive. [wiki]</a> Structural components, like the reactor vessel that surrounds the core, become intensely radioactive over the course of a reactor’s lifetime. When a reactor is decommissioned, the vessel must be disposed. Like fission products, this waste has a short half-life around 5 years, and is intensely radioactive. [Shirk]</a> Coolant liquid and other components of the reactor that aren’t directly exposed to intense radiation are often still classified as nuclear waste, and are disposed as Low Level Waste in shallow pits in the desert: [wiki]</a> </figure>The two key points for a traditional uranium reactor are (a) only a tiny percentage of the uranium fuel is actually used and (b) the actinide waste is by far the most annoying part of the waste stream. The mind-blowing thing is that these are the two areas where molten salt reactors appear to excel.Continuous reprocessing in a molten salt reactor allows it to burn 92% of the input fuel, as compared to 2% in a traditional uranium reactor. [ORNL]</a></li> A “fast breeder” version of a molten salt reactor has fast neutrons in the reactor core. These neutrons easily interact with the actinides, transmuting them into fissile isotopes and then fissioning them to produce energy. In other words, molten salt reactors burn actinides. The same is not true for traditional uranium reactors because they have thermal (slow-moving) neutrons in the reactor core. Neutrons at these slower speeds don’t interact with the actinides, so you can’t burn actinides in a traditional uranium reactor.</li></ol> So from the perspective of waste production, molten salt reactors appear to be the obvious winner. In fact, molten salt reactors are often called “actinide burners” because they would allow us to get rid of old actinide waste from traditional uranium reactors. Closing thoughts</h2>The biggest costs for nuclear reactors are safety systems and proper handling of the waste stream. As best I can tell, molten salt fast breeder reactors are significantly better than traditional uranium reactors in both of these categories. As a side note, it looks like using thorium as a fuel is not actually critical. Thorium can be used as fuel in molten salt fast breeder reactor, which is a benefit for long-term sustainability, but thorium has little relation to the cost of constructing a new reactor today.As of this past month, China now has a $350m institute with 140 PhDs plugging away on molten salt reactors. Japan may be starting its own program. [news]</a> These efforts are nothing short of awesome, and I wish the US would jump into the fray. But without massive congressional funding, it’s hard to know where to start. First nuclear reactor on kickstarter? :P Thorium 2012-12-10T00:48:12.000Z About a century ago, an adventurous Scandinavian discovered the first black thorium rock on a remote island in the Norwegian Sea. Now thorium is slowly heating up debates about the future of nuclear power, energy independence, and global warming.I wanted to get to the bottom of this surge in nuclear enthusiasm, and I was inspired by Peter Thiel’s lecture on energy markets</a>. This post encapsulates the surprising things I learned about thorium and nuclear reactors. Thorium’s Bold Claim</h2>The only naturally occurring radioactive elements that can be used to fuel nuclear reactors are uranium and thorium. uranium reactors are commonplace, but thorium reactors have been pretty experimental since the first one started up at Indian Point Energy Center</a>, New York in 1962. Nearly all of the world’s power-producing reactors run on uranium or its derivatives. This is where the debate heats up. Proponents of thorium argue that thorium reactors have big advantages over uranium-fueled reactors: Thorium is much more abundant on Earth than uranium.</li> Thorium is cheaper to extract and prepare than uranium.</li> Thorium isn’t very useful for making nuclear weapons.</li> Thorium reactors are inherently stable, so “nuclear meltdowns” can’t happen.</li> Thorium reactors produce dramatically less radioactive waste.</li></ul> Opponents point out that thorium reactors are technically challenging, are still unproven, and still produce radioactive waste. But these broad strokes paint thorium reactors as extremely promising, so it’s no surprise that India, China and the US are actively building experimental research reactors. This all sounds tremendously exciting, but honestly it seems too good to be true. We need to answer a lot of questions about the apparent advantages of thorium. Black Rocks, Red Sand, and Plain Old Dirt</h2>The first black rock picked up by that Norwegian was composed largely of a mysterious new element, and so in honor of the Norse god Thor it was dubbed thorium. Marie Curie would later discover that it was radioactive.But it turns out that thorium isn’t exclusive to snow-covered islands in Scandinavia. It’s actually surprisingly common: plain old dirt in your back yard has 6 parts per million (6 ppm) thorium. Large tracts of granite found throughout the world contain 13 ppm</a>. And reddish Monazite sand, which contains 2.5% thorium, is abundant in specific places. The important point is that thorium is ridiculously more abundant than uranium. And abundance matters when we’re talking about providing energy to the world. In fact, there’s so much thorium on Earth that the easily extractable reserves in the United States (10% of the world’s) could supposedly power the entire United States at current energy levels for the next 10,000 years</a>. It’s not exactly renewable, but it’s a much longer lifeline than oil. And it can be mined safely within US borders: most of the US reserves are concentrated in a 25 square-kilometer pileup of mountains straddling the border of Idaho and Montana</a>. The rest of the world’s extractable thorium reserves</a> are concentrated in India (25%) and Australia (10%), with the remaining 55% spread around nicely. It’s immediately obvious that the geopolitics of thorium are dramatically different than the drama surrounding oil in the Middle East. Got Sand, Want Fuel</h2>Once you’ve got some thorium-rich Monazite sand, there’s a straight-forward and well-known process</a> for extracting high-purity thorium. You mix the sand with sulfuric acid, which gives a nice gray mud; wash that with cold water and treat with a couple more common chemical solutions, and boom your thorium precipitates right out as a nice sludge. If you want fuel for a Molten Salt Reactor, you mix fluorine with the thorium to produce thorium tetrafluoride. Or if you want fuel for a solid fuel reactor, you have to sinter the thorium at very high temperature to produce thorium dioxide. The sintering process is complicated and expensive, but the fluorine process for Molten Salt Reactors is fast and relatively cheap. The wonderful thing about thorium is that this pretty much wraps up the entire preparation process. Let’s compare that to uranium. Uranium is either extracted from the ground as ore and then leached for uranium metal</a>, or the leaching can happen while the ore is still in the ground. The leached uranium solution goes through a similar chemical process to extract high-purity uranium oxide. But then things get complicated. uranium-235 and uranium-238 are chemically identical, but are different isotopes with correspondingly different nuclear properties. Uranium-235 is fissile, which means that if a neutron comes near it, an atom of u-235 will split in two, releasing a bunch of energy and two additional neutrons. If you have more u-235 nearby, those two neutrons will create a nuclear chain-reaction and tada! you have runaway nuclear reaction… sometimes escalating to a nuclear meltdown or explosion depending on the situation. But uranium-238 isn’t quite so excitable. u-238 is fissionable but not fissile, which means that you have to really slam a neutron into u-238 to split it apart. u-238 also releases a bunch of energy and a two neutrons, but those neutrons aren’t energetic enough to keep the reaction going. So, long story short: you need concentrated uranium-235 to keep the energy flowing in a reactor. Too much uranium-238 and your reactor will just cool down and stop. And this is where nature gets us vexed. Naturally occurring uranium is 99.3% u-238 (not fissile) and 0.7% u-235 (fissile, very useful). In order to run a reactor, you need at least 3-5% u-235 and to make weapons you need 95% u-235. Separating u-235 and u-238 isotopes is enormously expensive, because they’re so subtly different. Large numbers of expensive, high-speed centrifuges or gas diffusion systems must be used to separate and remove uranium-238 (which is ever-so-slightly heavier) from the mixture. During this process, the uranium oxide is converted to uranium hexafluoride, and large amounts of u-238 hexafluoride (Depleted uranium) are produced. Depleted uranium is widely used in ammunition, armor, etc. but we have another 700,000 tons stockpiled and unused. So preparing thorium is significantly easier and cheaper than preparing uranium, because you completely avoid the isotope separation step. Nuclear Fire</h2>Now that we have our raw nuclear fuel, either thorium or uranium, we need to get a nuclear reaction going and convert the resulting energy into electricity. That requires a nuclear reactor, which is basically a carefully designed clustering of nuclear fuel that outputs lots of heat. That heat is used to create high-pressure steam, which drives massive turbines that output electricity. There are many types of reactors, and each has a unique fuel cycle. But at its core, each reactor’s fuel cycle must include a fissile material, since that’s what keeps a nuclear reaction going. The primary fissile materials are uranium-233, uranium-235, plutonium-239. What happened to thorium? Well, uranium-233 is bred from thorium. And where’d this plutonium come from? plutonium-239 is bred from uranium-238. So this gives rise to the idea of breeder reactors. Breeder reactors are loaded with lots of fertile fuel like u-238 and thorium, and then get an initial boost from u-235. The thorium and u-238 then each get morphed into fissile elements, which generate the nuclear reaction that keeps the whole thing running.Holy Smokes, Serious Engineering Starts Here</h2>And this is where things start to get really murky and complicated. There are dozens of proposed or tested reactors of all different types, and each one has a different fuel cycle, waste profile, and cost. The waste profiles seem particularly complex to predict, and the costs associated even harder. After reading about many of the different designs I came to the unsurprising conclusion that nuclear engineering is, in fact, extremely complicated. The goal, of course, is very cheap power. Where cheap takes into account the whole process, from initial conception, building the reactor, operating the reactor, all the way to properly handling the long-term waste produced.How do these costs break down? And does thorium really reduce those costs? According to world-nuclear.org</a> 14% of the cost of nuclear reactors is the fuel and 10% is waste disposal. The remaining 76% are construction and operating costs, mostly associated with high levels of training, safety and security required for the reactors. The cost of redundant safety systems in nuclear reactors is staggering. For example, a 400 MW coal fired plant in Arizona cost $1B</a> (2010 dollars) to build, while a 2260MW nuclear station in South Carolina cost $15.6B</a> (2010 dollars). In terms of construction costs, the nuclear plant was nearly 3 times as expensive. Typically this is due to financing overhead and the intense requirements for redundant safety and security. Keep in mind that the coal plants subsequently spend way more $$ on the coal… 78% of total coal plant costs are the fuel. Let’s summarize how thorium affects the cost breakdown: Thorium fuel would cost much less than the current 14% of total costs, but the fuel is not really the main expense for nuclear reactors.</li> Waste disposal is a hot topic, but doesn’t appear to be a primary expense either. Most thorium reactor designs are expected to produce less waste, particularly waste that isn’t as long-lived. So waste disposal for a thorium reactor is definitely cheaper, plus it would reduce environmental concerns overall.</li> Security and proliferation issues surrounding nuclear power increase costs significantly. Although proponents of thorium claim that thorium reactors are proliferation-proof (see top), a recent article in Nature</a> suggests that thorium can actually be used quite easily to produce weaponizable uranium-233. So the cost savings on security is questionable at the moment.</li> Safety features of nuclear plants seem to dominate the cost. There are many claims about the inherent safety features of thorium Molten Salt Reactors. But those claims have yet to be proven in working prototypes. If thorium reactor designs and prototypes could prove the claims of inherent safety mechanisms, then thorium could dramatically reduce the cost of nuclear power.</li></ol> While the debate goes on, we’re really just waiting for someone to buck up, build some thorium reactor prototypes and see what’s what. Here are some people making moves: The Weinberg Foundation</a> is actively financing Molten Salt Reactor experiments.</li> Bill Gates and others have invested</a> in TerraPower</a> which is developing a traveling-wave reactor.</li> Jim Kennedy has a novel idea to create a Thorium Bank</a>. Thorium is often a nasty byproduct of rare-earth mining, and they have to figure out what to do with it. The Thorium Bank would take it off their hands and look for other uses… pending congressional approval.</li> Norway and Westinghouse are trying to use thorium fuel in a traditional reactor.</a></li></ul> Do you know of other serious efforts to experiment with thorium power? Super interesting topic, would love to hear what everyone thinks. Better Email Search 2012-07-27T23:49:34.000Z Email holds all of our conversations, contacts, notes, and plans. All that information is languishing in my archive folder. I should be able to access this vast personal knowledge-store as if it were an extension of my own, faulty memory.Sparrow</h2>I use Sparrow as my email client and it’s been great. Except for search. Sparrow’s search is a nightmare. Here are my most recent searches:On my way to a meeting, what’s the address again? I’m on time, right?</li> What’s our federal tax id? I think it’s in that one email… ? … ah.</li> What’s my password for DDDDDD? (yeah… I shouldn’t, but come on, you do it sometimes too ;)</li>Where are the mockups Ian sent out last week? (for some reason the word mockup is never in the email and I’m just screwed trying to find the damn thing.)</li></ul> I’m constantly searching for old emails. Here’s what it looks like in Sparrow on the iPhone:</figure>Sparrow’s from/to/subject/all search options are standard for email search, but infuriating. I don’t care!!! I just want the mockup! Shouldn’t “Ian mockup attachment” be good enough to return some imperfect but probable matches? Improving Search</h2> One Search Box</h3>I don’t remember whether it was from me or to me. I don’t remember whether this keyword was in the subject or the body. I’m trying to find it because I don’t bloody remember the content! Give me a single search box like Google and just figure it out.Get Cuddly with Fuzzy Matching</h3>Not only do I not remember whether this keyword was in the subject or the body, I probably don’t even have the right keyword. I’ve probably gotten my brain frozen onto the wrong synonym for “mockup”: screenshot, layout, shot, page, design, etc. Give me a hand here and do some fuzzy matching.I’m Talking Here</h3>On mobile I want to dictate questions verbally. The keyboard is slow, anti-social, and soon Siri will have hooks for apps</a>, right? On my laptop I’d rather type keywords. Typing up the whole question is soooo AskJeeves, and I’m still not ready to chitchat with my Macbook in a quiet office setting. Well, actually I might be cool with that. Dunno, try me. Unnecessarily Expanding Scope Cause That’s Fun</h2>Could you start building a knowledge graph of my personal data? Just start answering my questions straight up: “Your Federal Tax ID is 10-10011”. Similar to that new sidebar on Google Searches</a>. As long as you’re searching all my email, would you mind indexing my Dropbox? My interesting files are all cloudy now, so the problem seems easier and cleaner than the old Google Desktop search. Closing</h2>It seems like our email overload problem is partly due to the brittle inaccessibility of it’s vast, contained knowledge. Once I archive an email, it’s very difficult to get back. That means I’m constantly trying to memorize parts of the content instead of offloading this gargantuan memory requirement to the computer. If archived email content was more accessible, email would be more useful and less overwhelming. Build your CRM in an afternoon with Google Scripts 2012-06-24T23:51:38.000Z We’re expanding our private beta at Segment.io</a>, and in my dual frontend dev/account manager role I need a time-saving, flexible CRM. I’ve tried Salesforce and Highrise in the past, but neither one was a pleasure to use—I burnt out on manual data entry pretty quick. Our new solution was quick to build and solves all of my current problems. As a startup that’s still figuring things out, there are two main things we need from a CRM: Flexibility: I need to constantly revise what user info is stored and displayed. Day-to-day we want to know when our beta testers last logged in. But next week we might decide to send our beta testers fruit baskets, and suddenly physical mailing addresses will be much more important.</li> Automation: Most of the data we need is gathered from various web endpoints: compete.com for an estimate of monthly actives users</li> an internal api for most recent login date, current events/day, …</li> … etc …</li></ul></li></ol> Another tool worth mentioning is Intercom.io</a>. It goes a step further than Salesforce and Highrise because it collects a bunch of data for you, but honestly I’m not interested in our signups’ profiles on Vimeo, Google+ or Foursquare… it seems a bit creepy. If you sign up, I want to know (a) what is your business about and (b) what analytics solutions are you using right now, so that we can better address your analytics needs. So what to do?</h2>A few weeks ago my friends at IronSpread</a> got me thinking about a new approach: keep a list of leads in a spreadsheet, and use scripts to automate data collection about those leads. Flexibility? ✓ It’s a spreadsheet.Automation? ✓ You can do almost anything with Google Apps Scripts</a>. Google Apps Script for Google Docs is like Visual Basic macros for Excel. Except you get all kinds of magic. The most useful components for us are: Cell manipulation:</h3>sheet.getRange(2,1).setValue('Toasters');</code></pre>This sets the B1 cell to have text ‘Toasters’.Fetching external data:</h3>var response = UrlFetchApp.fetch('https://segment.io/secret'); Utilities.jsonParse(response);</code></pre>This allows us to retrieve info from our internal APIs, compete.com, and our beta tester’s websites. Now whenever someone signs up with an email@interesting-domain.com, the spreadsheet CRM goes ahead and reads…the business’s website title meta-tag (so we know what their business does)</li> estimated monthly active users</li>what analytics solutions they currently have in place This helps us write well-suited introductions to each customer, and gives us a great feel for who’s interested in beta testing.</li></ul> Google Apps Script also gives you access to Gmail, which seems promising for a CRM, though I haven’t tried using it yet.If you want to get started and build your own, go to docs.google.com</a>, create a new spreadsheet, and click Tools : Script editor. Later you can run your script using Tools : Script manager. The documentation</a> is also useful. One Year Since Leaving MIT 2012-06-15T23:52:39.000Z I left MIT one year ago - I had one year of coursework left as an undergrad in Aerospace Engineering. After [a long story] I co-founded Segment.io</a> with Ilya</a>, Ian</a> and Calvin</a>. I’m incredibly happy with my decision, and I want to share some reasons why the decision to leave was right for me. First: my family, and especially my fiancee(!) have been incredibly supportive. It’s WAY EASIER when they smile, listen and help you through the rough times of starting a company. I’d have given up long ago if not for them. Not to say it was a perfectly smooth ride: on first meeting Erika’s parents, I told them “I’m gonna give this entrepreneurship thing a try.” Her parents deserve some serious credit… I’m surprised the conversation didn’t end in laughter right there. My favorite professors have mostly gotten over their shock. I was back for MIT’s graduation ceremony last week and got to say hi to a few of them. They were mildly surprised to see that I was not, in fact, broke, hungry, and homeless. Our progress delighted them, although they expect me to finish up at MIT eventually. No worries, these profs aren’t going anywhere. It’s also fascinating to observe the difference between leaving school with purpose (let’s start a company!!), and getting suddenly shoved out of school right after this odd thing called “graduation”. Today I live with my co-founders on Russian Hill in San Francisco. It’s a grand thing, living with your college roommates in an amazing apartment, managing your own time and working on something you chose out of your own interest. At the same time, many of our friends from MIT/RISD and high school are now suddenly a part of the adult working world. And whoa is it a shock. A rare few of them are overjoyed in their realizations “Wow! I’m paid so much I can buy a house, like, right now!”, but many of them are now soul-searching for a job that actually fits their credentials. Some are re-training in radically different fields (humanities ⟶ computer science) and others are going back to school in… oh, computer science. This time around though, they’re training with intent. Leaving school with a purpose feels a lot better than leaving without a purpose. So, while I don’t have any reason to specifically recommend leaving school early, I do recommend leaving school with a purpose. For me that happened a year early. Building a Movie Showtimes API 2012-04-30T23:55:22.000Z I built TheReelBox.com</a> to demonstrate an easier way to find nearby movie showtimes than Fandango or Google Movies. (More importantly, it generates demo data for showing off Segment.io</a>.) It turns out that movie showtime data is difficult to get and the APIs cost a lot of money to use: you have to call Fandango, West World Media, or Tribune Media Services just to discuss access to the API. Obviously I was not going to do this just to throw together a side project. Enter Yahoo! Query Language</a>, which allows you to convert any web content into an API by defining a parser. Your client-side javascript makes JSONP requests to YQL, it retrieves the web content, applies your parser, and returns formatted XML or JSON. It lets you create an API where there was none before. A Few Caveats about YQL</h2>YQL has complicated request limits</a>. Executing one showtimes query uses about 1 million execution units (50 million maximum per query.) There’s also a limit to 10k or 100k requests per day. Also consider what happens every time you need some showtimes: TheReelBox fires a JSONP to YQL, which requests the appropriate Fandango page, which is then parsed in YQL, converted to JSON and returned to TheReelBox. It’s crazy slow. To speed things up I needed a sort of “API Caching Layer”. Firebase</a> ended up fitting the bill perfectly. I’ll write about that another time. The online interface for YQL has lots of issues. It’s freaking impossible to debug YQL parser problems (you kinda just stare at the code and hope for the best…), and their online console deleted all my files occasionally… but hey, it generally works. Reverse Engineering the Ticket URL</h2>Fandango provides urls to affiliate advertisers</a> for purchasing tickets, but you can’t link to the exact movie+showtime+theater, so the user has to re-select which time and theater they want. I wanted links on TheReelBox to take users to the final purchase page, and this is where things got interesting. First, I discovered that Google Movies and Movies.com have direct links to the Fandango ticket purchase page - this is special among affiliates. Here’s an example Movies.com referral URL: https://www.fandango.com/Transaction/Ticketing/redvines/ticketboxoffice.aspx?row_count=1723543009&tid=AABBF&mid=139936&wssaffid=11828_MoviesDotCom&wssac=131</code></pre>The base url is static and simple, but the GET parameters are interesting.row_count</code> — this changes for every movie, theater and showtime, so I assumed it’s a unique reference to the ticket/showtime the user wants to buy.</li>tid</code> — according to imerchantnetwork.com</a> this is a “Terminal ID” used for card transactions.</li> mid</code> — for internal Fandango links this changes by movie, so I figured it’s a “movie id”. Confusingly, imerchantnetwork.com claims this is a “Merchant ID”… dunno.</li> wssaffid</code> — this parameter is standard in affiliate links, and appears to be a unique ID for each affiliate.</li> wssac</code> — this parameter is also standard in affiliate links, no clue what it represents.</li></ul> Can we put together the necessary information to create our own direct checkout links? It turns out that row_count</code>, tid</code>, and mid</code> are all used by Fandango in their internal urls, so we can snatch these parameters in our YQL parser. Through the affiliate program you can look at your generated affiliate links to find the wssaffid</code>, and wssac</code> numbers. So, boom! Yes we can link directly to the purchase page with a little work. Here’s an example with TheReelBox affiliate info plugged in: https://www.fandango.com/transaction/ticketing/redvines/ticketboxoffice.aspx?row_count=2553707866&mid=145763&tid=AAUJF&wssaffid=11836&wssac=123</code></pre>Now, I had no idea whether this was working or not, and then someone bought a ticket. The commission came through perfectly. Finally, since you’re probably curious: TheReelBox users have clicked through to Fandango and purchased $256.00 worth of tickets, generating $2.10 in commission - 10 cents a pop. Luckily, Fandango won’t mail a check until commission hits $50.00. Currently I estimate that the check will arrive on February 9, 2018… I’m stoked :)This is a follow-up to questions asked on HN when TheReelBox launched</a>. Using the Heap Profiler in Chrome Dev Tools 2012-03-08T00:57:51.000Z At Segment.io</a> we have a one-page app used to explore analytics data. Good memory management is a very important us, and the Heap Profiler in Chrome developer tools is the perfect tool for the job…. it’s just a bit hard to use. My main use case for the Heap Profiler goes like this: Find the object that I’m interested in… but how do you track down specific objects in this mess of memory references?</li> Check the object’s memory usage… this is where you have to go learn about shallow and retained size. Extremely helpful diagrams can be found here.</li> Try deleting all references to the object.</li> Make sure the object is really gone… but how do you know if something actually got deleted?!?! The total memory usage for the whole tab is an ok indicator for large objects… but memory usage jumps around and with smaller objects you’re out of luck without the profiler.</li></ol> This post explains how we use the profiler to (1) Find the object of interest and (4) make sure the object got deleted. Some of the details are specific to apps using Backbone.js</a>. Four main views</h2>The Heap Profiler has four main views Summary, Containment, Dominators and Comparison. The Summary, Containment and Dominators views are useful for tracking down specific objects, and the Dominators and Comparison views are useful for checking that things have actually been deleted. Here’s how we use each one:Summary view</h2>This view is good for tracking down specific objects based on their “type” (constructor name), because it shows objects in memory grouped by their constructor name. For example, Dates are grouped under “Date” and Backbone.js objects are grouped under “child” because of naming in the backbone view constructor. In the minified version of Backbone 1.7.1 the constructor names change, so Backbone objects appear under “d” and the constructors appear under “q”. Here’s a screenshot of one of our distribution plot objects “d @94543” found in the summary view:</figure>Containment view</h2>This view is good for analyzing objects that are referenced in the global namespace… basically anything you put on the global window variable. For example if you we window.seg and we want to see what it’s keeping around in memory, we open Containment -> the first DOMWindow -> seg. Here’s a screenshot of finding window.plot1 “d @94543” in the Containment view.</figure>Dominators Tree view</h2>This view is a good way to verify that your references are all properly contained (no unexpected references hanging around), and that deleting things is really working.The view shows a tree of nodes in memory that “dominate” other nodes. From wikipedia</a>: a node d dominates a node n if every path from the start node to n must go through d. This means that by deleting the dominator node d you remove all references to any dominated nodes n. So in effect, this tree shows you all the low-hanging fruit: if you delete d, you delete n. If you expected to see a particular object being dominated, but don’t, then you probably have a hanging reference to it somewhere! For our distribution charts I see a node “d @94543” that contains a bunch of other nodes. From clicking on each node I can figure out what they are. For example, the first node has a retaining path “(GC roots)@3[751]._->w.zoom->b[0].on{literals_or_bindings}{content}.d3” and that node’s children are “…d3.data”, “…d3.val”, “…d3.el” etc. So now I piece together that the first dominated node was the “this.d3” object inside a plot view, and the original dominator “d @94543” is a distribution plot object, and furthermore, if I delete “d @94543”, then all of the dominated nodes will be cleaned up as well, since because they are dominated there are no more references to them anywhere else. When I close and delete the reference to the distribution plot view, the node “d @94543” disappears from the dominators tree and memory usage drops by 3MB, so cleanup seems to work as expected. </figure>Comparison view</h2>This view is the best way to verify that deletion is working properly. The view allows you to see the diff of two memory snapshots, showing you the delta in reference counts, freed memory, etc. The tricky/weird thing here is that in order to see what changed from Snapshot 1 to Snapshot 2, you want to first click “Snapshot 2” in the left hand column and then compare to “Snapshot 1”. When we delete objects in our code, I also see a whole bunch of deleted DOM elements, array objects, strings, closures, and numbers. Here’s a screenshot of the comparison view after a deletion:</figure>Here are some links to other useful resources about the heap profiler:http://code.google.com/chrome/devtools/docs/heap-profiling.html</a></li> http://zetafleet.com/blog/google-chromes-heap-profiler-and-memory-timeline</a></li> http://blog.chromium.org/2011/05/chrome-developer-tools-put-javascript.html</a></li></ul> How fast could you cross the country (without killing yourself)? 2012-01-03T00:58:53.000Z Crossing the United States on a train is an incredible experience. North Dakota fields ooze an evil early-morning fog that will make your spine shiver. The Montana Rockies tower suddenly from the endless plains. When you slip by at 40,000 ft in an aluminum tube you are missing this magic.So why not take the train? Because it takes 3 days @ $208 one-way</a> to get from Boston’s South Station to Seattle’s King St. Station</a>, a trip of about 3,000 miles. I would take the train every time if it took less than a day and still didn’t cost a fortune. So less than a day would be cool, but…. just how fast could you cross the country (without killing yourself)? The question is NOT about technological limitations, those change every day. The question is really about the “without killing yourself” part. Magical Tech</h2>For the technology, let’s assume something like a vacuum tube with a maglev train, unrestricted by air resistance and without physical contact points to a physical track. The hypothetical train’s deceleration could transfer energy back out, so the whole system would be extremely energy efficient…. low variable costs per trip but extremely high fixed costs to build the system.Without Killing Yourself</h2>What about physiological limitations? Martin Voshell has put together a fascinating history of US Colonel Stapp’s experiments on acceleration and the human body (section 2.1</a>). In 1954 Colonel Stapp survived 46.2 g’s, decelerating “eyeballs out” from 632 mph to 0 mph in 1.4 seconds. This a bit extreme for civilian transport, especially since this was a momentary peak and not sustained. A 1960 technical note from NASA</a> explains that pilots in centrifuges tolerated accelerations of 17 g’s “eyeballs in” and 12 g’s “eyeballs out”. According to NASA</a> the Space Shuttle has a maximum acceleration was 3 g’s, which Wikipedia claims</a> is “largely for astronaut comfort.” Given that “eyeballs in” (accelerating while facing forward) is more tolerable, let’s work with those numbers. Assume that the seats on our futuristic maglev vacuum-tube train can rotate 180 degrees so that deceleration is also “eyeballs in.” Reasonable accelerations seem to be 3 g’s for comfort, or 17 g’s for “tolerable”/”not dead, yet… just a fleshwound!” Start Your Calculators</h2>Let’s assume our maglev can sustain maximum acceleration halfway across the country, then decelerate the other half, which is as fast as you can go. Here’s a plot of cross-country travel time vs. sustained acceleration.</figure>Constantly accelerating/decelerating at 3 g’s will get you from Boston to Seattle in just under 15 minutes. If instead you want to be crushed into your seat and blacked out at 17 g’s, you can get to Seattle in about 7 minutes. North Dakota would blow by in about 16 seconds… probably defeating the whole eerie fog experience. You can find the original plot & equation in metric units here</a> (good work desmos</a>, though an embeddable version and the ability to label the axes and annotate the plot would be awesome!) Another interesting by-product of accelerating continuously halfway to your destination is that the time required to get to the destination scales with the square root of the distance…. so travel times don’t vary as much as you would expect. This table shows one-way travel times for a 3 g acceleration: Beijing: 20 minutes to cross 11,000 kmSeattle: 12 minutes to cross 4,000 kmChicago: 7 minutes to cross 1,400 kmNew York: 3 minutes to cross 360 km You can find the original plot and equation in metric units here</a> (time in minutes vs. distance in kilometers). As far as human limitations go, rail transit clearly has a lot of room for improvement. A ~350x reduction in travel time for cross-country rail trips is possible, purely from a physiological perspective :) For a much more thorough, and brutally honest analysis of urban transportation: http://swiftprt.com/blog/2011/12/the-future-of-ground-based-transportation-systems/</a> Testing our UAV in an Underground Parking Garage 2010-12-19T01:00:46.000Z At the end of the Spring 2010 semester, Mark and I built (and rebuilt, and rebuilt, and rebuilt) a small UAV. The UAV was controlled by two Arduino microcontrollers and a whole suite of sensors for measuring orientation, airspeed, and altitude.</figure>We tested the UAV in the parking garage underneath the Stata building. Flying inside has some benefits like no wind, but some major drawbacks… watch the video for some spectacular crashes.</iframe></div>Testing our UAV “Wild Goose”, Spring 2010 at MIT</figcaption></figure>Eventually the craft was able to take off, maintain steady level flight, then descend and land gracefully! Very fun project. Many thanks to Prof. Dave Darmofal</a> in the Aero-astro department at MIT for approving funding for our small-but-extremely-time-consuming project. Here’s our Project Proposal</a>, and the Final Report</a>. Give My Smartphone More Sensors 2010-12-02T01:01:50.000Z I’ve been thinking about what the mobile revolution means, and I agree with Paul Graham’s points</a>. Mobile devices are our constant connection to rest of the world, and their capabilities will continue to expand. The question is… how? Hardware is the Final Word</h2>While software can do some pretty crazy stuff, the capabilities of a device are fundamentally limited by their hardware. The hardware can improve in a couple ways: the data rate can get faster, coverage can get broader, the battery can last longer, and we can introduce fundamentally new sources of information. The last is the most interesting and revolutionary. From the end of Paul’s essay comes the validation of that idea: It has turned out to be a great thing that Apple tablets have accelerometers in them. Developers have used the accelerometer in ways Apple could never have imagined.—Paul Graham</blockquote> Personal Data Hubs</h2>Mobile phones accompany us almost everywhere we go, and I believe that in the next decade they will become hubs for a host of sensors and other devices in our clothes, bags, glasses… Every new sensor added to this growing hub will create a miniature revolution in our daily lives. Biomedical Sensors</h2>What if you could track your heart rate, levels of glucose, leptin, hormones, temperature, blood pressure… all from a bracelet, that communicated via bluetooth to your phone and a web service, providing you with instant and constant health information. There are all sorts of cool things you could do with that! It would certainly create some changes in the health care industry. Sensors, sensors, sensors, sensors…</h2>The future is in more sensors. It will lead to context-aware helper-devices. We will call it a HALper… or maybe a halp. It will be awesome. Onboard Video from a 12ft Rocket 2010-11-18T01:03:07.000Z This summer I worked at the Naval Postgraduate School in Monterey, CA on the Solar Cell Array Tester</a> (NPS-SCAT. ha. ha.) It’s a nanosatellite, and it’s supposed to launch on SpaceX Falcon 1E in April 2011! I also had some fun with the rocket team, working on an autonomous parasail that was supposed to be popped out of the 12 ft rocket close to apogee. The parasail didn’t pop out, but there was a totally ridiculous onboard video of the launch. We launched way out in the Mojave Desert. Mad props to Adam Yingling and the rest of the team for making the video. </iframe></div>NPS 12ft Rocket Launches in the Mojave</figcaption></figure> Datamining News Channels to Determine National Interests 2010-11-16T01:04:15.000Z NewsMiner is a C# program that mines CNN, Reuters, Xinhua and RIA Novosti for casualty counts around the world. The data is aggregated as a list of events: time, latitude, longitude, magnitude. Once the scraping for data is complete, the data is plotted on a world map. The miner is more likely to pick up frequent burst reports than lump-sum reports. For example, mined data from CNN indicates that CNN doesn’t report very frequently on Sudan, while it reports on Iraq quite frequently. This is a clear projection of national interest.CNN’s reported casualties</h2></figure>Iraq, Afghanistan and Pakistan show clear signs of unrest. Note that some locations are surprisingly underreported, e.g. Sudan. The counts seem well correlated with U.S. popular interests, and a lack of investment in most of Africa. There is a distinct lack of coverage in the F.S.U.Reuters’ reported casualties</h2></figure>Note that Reuters appears to have much better coverage of Africa and former British colonies in general. Still a distinct lack of reporting in the F.S.U.Xinhua’s reported casualties</h2></figure>Note much better coverage of the world (overall) than CNN. East Africa is particularly well covered, aligning well with the idea that China is extremely interested in their growing African investments.RIA Novosti’s reported casualties</h2></figure>The F.S.U. is much more thoroughly covered, aligning well with the idea that Russia desires a sphere of influence on their borders. The lack of coverage in developing Africa would seem to suggest that Russia is not a net exporter of investment. Also surprisingly poor coverage of Iraq and Afghanistan. Notes:(1) The web searches on Reuters, CNN, Xinhua and RIA Novosti were wildly abused in the production of these maps.(2) OpenGeocoding.org</a> was used to geocode the reported locations into latitude and longitude.(3) ws.geonames.org</a> was used to reverse geocode the coordinates into country codes.(4) gunn.co.nz</a> was used to turn data into maps. Collapsing Binary Star Systems - Visualizations 2010-10-06T00:04:43.000Z As a UROP project I produced some visualizations and audio-zations of gravitational waves, orbits and spin wobbles. Some of the visualizations are for extreme mass ratio systems</a> and others are for binary systems</a>. You can read more about it at the research page for Professor Scott Huges</a>. Semi-Truck Aerodynamics 2010-09-16T00:05:09.000Z Mark Chodas and I put together a project to test the viability of boat-tails as a way to reduce drag on semi-trucks. We built a 1/27th scale model for initial tests at the MIT Wright Brothers wind tunnel. The tests showed a 40-50% reduction in total drag using the equivalent of a long 3 meter tail. This translates to a 25% reduction in fuel consumption, or $35 billion per year in the US if every semi-truck was outfitted with a long tail. </figure>Further tests tests were scrapped after we discovered there’s a legal limit on the length of drag-reducing airfoils of only 5 feet :( Huge N-Body Simulations 2009-11-06T01:07:10.000Z During high school I wrote a C++ program that simulated thousands of masses and their gradual accretion via mutual gravity. Some simulations were designed to model the early universe: see this paper I wrote for Math 324</a> at the University of Washington. Here’s another simulation designed to model the formation of the solar system: </iframe></div>n-body gravity simulation (a bit dark, fullscreen to see it well)</figcaption></figure> Measuring the Moon's Gravity... or Seismic Intelligence Gathering 2009-08-22T00:08:07.000Z Due to a miscalculation, I thought I could measure the position of the Moon using the analytical balance in my chemistry class. By the time I had discovered my physics error, I already had the experiment set up and I was collecting a mass measurement every 5 seconds. The moon’s oscillatory motion didn’t show up in the data, but I could tell when school was in session and (probably) when Puget Sound Energy was switching between generators. Without prior knowledge, I was able to conclude that my teacher had come in on a day off and moved around in the back storage room where the experiment was set up.Here’s an old PowerPoint presentation</a> explaining the results.

6. Profitable</h2>
How you know:</strong> your cash balance is rising, and net income is positive.</p>
Freedom from outside capital. Cash balance is growing, even without new business. The promised land.</p>

Improving Search</h2>

Sensors, sensors, sensors, sensors…</h2>
The future is in more sensors. It will lead to context-aware helper-devices. We will call it a HALper… or maybe a halp. It will be awesome.</p>

Peter Reinhardt

Over-Regulation is Doubling the Cost

Judging Product Market Fit

Driving Data as a Defensible Moat for Self-driving Cars

Finding Product Market Fit

Startup Finance for Founders — Part II, Strategic Finance

Startup Finance for Founders — Part I, Accounting

Replacing Middle Management with APIs

Milestones for SaaS Companies

The Impact of Self Driving Cars

MVP Doesn't Mean Anything

Online Education's Dirty Secret — Awful Retention

radioactive.js

Gravitational Lensing to Observe Ancient Earth

Thorium Reactors

Thorium

Better Email Search

Build your CRM in an afternoon with Google Scripts

One Year Since Leaving MIT

Building a Movie Showtimes API

Using the Heap Profiler in Chrome Dev Tools

How fast could you cross the country (without killing yourself)?

Testing our UAV in an Underground Parking Garage

Give My Smartphone More Sensors

Onboard Video from a 12ft Rocket

Datamining News Channels to Determine National Interests

Collapsing Binary Star Systems - Visualizations

Semi-Truck Aerodynamics

Huge N-Body Simulations

Measuring the Moon's Gravity... or Seismic Intelligence Gathering

Peter Reinhardt

Over-Regulation is Doubling the Cost

Judging Product Market Fit

Driving Data as a Defensible Moat for Self-driving Cars

Finding Product Market Fit

Startup Finance for Founders — Part II, Strategic Finance

Startup Finance for Founders — Part I, Accounting

Replacing Middle Management with APIs

Milestones for SaaS Companies

The Impact of Self Driving Cars

MVP Doesn't Mean Anything

Online Education's Dirty Secret — Awful Retention

radioactive.js

What else can we learn by visualizing radioactive decay?</h2>First, you’ll quickly discover that radioactive waste comes in three flavors based on the half-life of the material:</p>

Gravitational Lensing to Observe Ancient Earth

But then there’s noise.</h2>The biggest black holes sit at the center of galaxies and have masses millions of times bigger than our Sun.</p>

Thorium Reactors

Thorium

Better Email Search

Sparrow</h2>I use Sparrow as my email client and it’s been great. Except for search. Sparrow’s search is a nightmare. Here are my most recent searches:</p>

Improving Search</h2>

Build your CRM in an afternoon with Google Scripts

One Year Since Leaving MIT

Building a Movie Showtimes API

Using the Heap Profiler in Chrome Dev Tools

Dominators Tree view</h2>This view is a good way to verify that your references are all properly contained (no unexpected references hanging around), and that deleting things is really working.</p>

How fast could you cross the country (without killing yourself)?

Testing our UAV in an Underground Parking Garage

Give My Smartphone More Sensors

Sensors, sensors, sensors, sensors…</h2>The future is in more sensors. It will lead to context-aware helper-devices. We will call it a HALper… or maybe a halp. It will be awesome.</p>

Onboard Video from a 12ft Rocket

Datamining News Channels to Determine National Interests

Reuters’ reported casualties</h2></figure>Note that Reuters appears to have much better coverage of Africa and former British colonies in general. Still a distinct lack of reporting in the F.S.U.</p>

Xinhua’s reported casualties</h2></figure>Note much better coverage of the world (overall) than CNN. East Africa is particularly well covered, aligning well with the idea that China is extremely interested in their growing African investments.</p>

Collapsing Binary Star Systems - Visualizations

Semi-Truck Aerodynamics

Huge N-Body Simulations

Measuring the Moon's Gravity... or Seismic Intelligence Gathering

Sensors, sensors, sensors, sensors…</h2>
The future is in more sensors. It will lead to context-aware helper-devices. We will call it a HALper… or maybe a halp. It will be awesome.</p>