Parrot Postage, Parrot for short, turns a card you make on your phone into one that lands in a mailbox. You design it in the app: upload a photo, write a message, and, if you want, let it generate the handwriting and the cover art. Parrot prints it, handwrites the envelope, stamps it, and drops it in the mail through USPS. You watch it move from submitted to delivered.

The positioning is "real beats impressive." The note is meant to read as genuinely from you, so the product pushes toward believable, low-key, human messages rather than the flowery language on a store-bought card. A card runs about seven dollars, all in.

I built the product and the operations from zero, raised a pre-seed, and hired the first team. It runs as one codebase with four moving parts: a card-creation app that compiles to web, iOS, and Android from a single source; a backend that renders a print-ready PDF matching the on-screen preview exactly; an internal dashboard operators use to work the mail queue from awaiting-print to mailed; and a helper app that drives the physical printer.

The harder parts are the ones that make it feel human: turning a typed message into real handwriting, keeping the printed card pixel-faithful to what you designed, billing on a ledger that never double-charges, and logging every card so nothing gets lost between the screen and the mailbox.

Three ways to send run on the same rails. Individuals send personal cards. Businesses run bulk campaigns with mail-merge and a personalized card per recipient. And a partner API lets other products call Parrot's handwriting generation and put real handwriting inside their own apps, the first of them being Handfelt.

Zillow is one of the most fun sites on the internet. You click around a neighborhood and every house wears a number, an estimate of what it is worth, and you never have to ask anyone. Under the hood it is just a pricing model pointed at houses.

Three Pillars did that for companies. You could browse a library of businesses and see what each one was worth and how it was doing, the same click-around curiosity, with businesses in place of houses. We even shipped a Chrome extension: land on any business listing, hit capture, and it would build you the model on the spot.

The catch is that a house hands you clean comps and a business does not. There are no tidy three-statement financials sitting on the corner coffee shop. Getting from almost nothing to a real, defensible number was the whole game.

Coming out of an MBA I could have taken a normal job. I spent a year on this instead, and not because I like starting companies. For a private business the important numbers are a guess: what it is worth, whether its performance is any good. That judgment has always been gated behind people you pay and degrees you earn, and AI had just made it possible to hand a first draft of it to anyone with a browser.

That kind of opening only shows up once in a while. It was worth a year to find out whether it was real.

Getting there meant working backwards from how a normal model does it. A traditional DCF starts from a top-line growth rate you assume and rides on a few blanket numbers. Three Pillars built the business up from its actual operating units instead, for a coffee shop, down to cups and croissants, then bounded every estimate against reality by reading public-company filings. A cafe pulls a comp like Starbucks' 10-K to anchor revenue per store and employees per store, so hundreds of granular inputs each stay inside what public markets actually show.

And because it was a real structured model, not AI writing a number into a cell, you could interrogate it with a sensitivity analysis across about five hundred inputs.

A new coffee shop feels like a blank page, but it isn't. Thousands are already open, and the big chains publish their economics to the decimal in their 10-Ks. So the model never guessed your shop from scratch. It read the giants' filings for structure, cost ratios, revenue per store, revenue per square foot, and leaned on the crowd of comparable shops for the range. It is the Moneyball move: no single one of them is your business, but in the aggregate they add up to a number you can stand on.

You can't hold ten thousand businesses in your head. Pillars could, and not just for coffee shops. Here is the idea in miniature, one target company you can actually move around:

A single number pretends to a precision it does not have. The tool's answer was to run the whole model thousands of times over, wiggling every driver at once, and hand you the range instead of a false-precise point. Toggle the drivers and re-run it. Fewer moving parts, tighter spread. This is a stripped-down stand-in for the real thing, which is still live atthree-pillars.com.

The response in customer conversations was strong. I won't name names, but the same reaction kept coming up:

It was credible enough that a roughly $100M legal case hired us to run the valuation.

This wasn't a thin wrapper over a chatbot. I wrote the reasoning agents, the full front and back end, and the gnarly data structures underneath. Most of the hard work in a system like this is the plumbing nobody sees.

And I did most of it with almost no money. I had master's and PhD engineers building alongside me, a few experienced advisors, a standing session with a fund of funds, and a development partnership with a finance company that wanted in. I couldn't pay much; they showed up anyway.

I stopped pushing it. The window to build it into a real business looked like it was closing faster than I expected, with commercial AI getting better at the exact thing that made Three Pillars worth using. I decided that wasn't a bet worth more years of my life, so I put it down and moved on.

The demand was never the question. The timing was.

Right after I stopped flying the V-22 Osprey, I spent three years modeling whether someone could build a plane to beat it. At Skyworks I worked directly for the chairman, a former University of Chicago trustee, as the person responsible for one question: was a next-generation aircraft, meant to compete with the Osprey, realistic to develop and to finance? The program contemplated hundreds of millions of dollars of planned investment.

I owned and built the full financial model, and not for one aircraft but for eight entirely separate ones. Each needed its own development budget, timeline, testing and prototyping plan, certification path, DCF, and set of fundraising tranches, all wired together so a change in one showed up everywhere. I worked directly with PhD-level engineers to keep the development timelines honest rather than optimistic, because that is the assumption everything else rides on.

The model let leadership make the real calls: prioritize requirements, adjust timelines, work out which of the eight aircraft actually mattered, and sharpen the raise. It was solid enough to build the documents behind a nine-figure fundraise. The chairman and board used it, and the board included a former Secretary of Defense. I built the case. I did not present or defend it in the room.

This was an internship, and it ran its course. I left with the model built and a clearer sense of how a nine-figure aircraft program actually gets priced: how much of it comes down to credibility rather than spreadsheets, and how development risk shows up once real money has to move.

Nearly every long-haul internet signal travels as light through silica glass fiber. Silica is cheap and clear, but it has a floor: past roughly 1.5 microns of wavelength it starts absorbing its own signal, so the light fades and has to be caught and re-amplified every so many kilometers down the line.

One glass doesn't have that floor. ZBLAN, a fluoride glass of zirconium, barium, lanthanum, aluminum and sodium, stays clear far deeper into the infrared. In the mid-IR band where silica quits, it can carry a signal with up to about 20× less loss. It has been known since the 1970s. Almost nobody uses it, for one stubborn reason.

As the drawn glass cools, a crystal can nucleate inside it. It'slighter than the glass around it, so it starts to rise, and rising drags the surrounding glass into motion. That disturbance is what grows the crystal and seeds the next one. On Earth a single nucleus can start the chain. In orbit it has no reason to rise, the glass stays still, and it mostly just sits there. Same cooldown, two gravities:

The part that mattered: everyone already knew all of the above. NASA and others have drawn ZBLAN in microgravity since the 1990s, and in 2024 a company pulled roughly 12 kilometers of it aboard the ISS. The physics question was settled. The businessquestion wasn't, because the ISS way is painfully slow. You're a guest in someone else's lab, rationed by crew time, and a finished spool can wait months for a ride home on the next return capsule.

reOrbital's whole thesis was that this is a throughput problem, not a physics problem. Put the production on reusable rockets instead of the station: short, dedicated runs (a few days in orbit) that come straight back down and fly again. Many fast cycles beat one long one. That's the number a factory in space lives or dies on: usable fiber returned per unit of time.

None of this was settled fact. It was the projection we were building against. A reOrbital run carried roughly 360 kg, so the bill for one launch is just the price per kilogram times ~360. As that price fell, the cost of flying our factory fell with it, from about$54,000/kg on the Shuttle, to $2,700/kgon a reused Falcon 9, toward Starship's $150/kg target.

And it doesn't slide down smoothly. It crosses thresholds. At Shuttle prices one launch runs into the tens of millions: no-go. At reused-Falcon prices it's about $970K, a real but survivable line item: economically viable. At Starship's target it drops near $54K a flight, roughly the ~$60K we were planning around, and cheap enough that the fiber inside is worth far more than the ride: valuable.

Drawing ZBLAN in orbit wasn't our idea. NASA and others had done it, and the ISS had made kilometers of the stuff. What nobody had really shown was whether you could make enough of it, fast enough, for the economics to hold up. That's the part I worked on: throughput per run, on a vehicle that could fly often enough to matter. It's a narrower and less romantic question than "manufacturing in space," but it's the one the business actually turned on.

I joined a senior space engineer already chasing the process; my job was to turn a promising run into something a customer and an investor could underwrite.

We took it through the New Venture Challenge, Booth's accelerator, and placed 2nd of 65, which came with $280,000. Duality, the national quantum accelerator, took us into its third cohort with another $50,000, and we opened an SBIR to pull in non-dilutive government funding.

Fair question, after all those numbers: if one launch could bring back that much fiber, why stop?

Because the piece we'd treated as solved wasn't. The underlying fiber-drawing technology wasn't nearly as mature as we thought, and you can model orbital throughput and price all day, but none of it matters until you can reliably draw good fiber in the first place. That base layer wasn't ready. We pivoted to work on it, but the path to a real product kept getting longer, and after about a year with the venture I moved on.

The economics were real. The technology under them wasn't there yet.

Long before any startup, I spent eight years flying the MV-22B Osprey for the Marine Corps. It lifts off straight up on two big rotors like a helicopter, then tilts those rotors forward and cruises like a turboprop, roughly twice as fast and far as any helicopter can go.

The job under all of it was simple to say and hard to do. Put 24 Marines into a landing zone in enemy territory, day or night, in any weather, on less than six hours' notice, sometimes launching off the deck of an aircraft carrier. Each of those flights was a call you could not take back, with other people's lives in the back of the aircraft.

That kind of work builds one specific thing: a tolerance for irreversible decisions made fast, on incomplete information, with real consequences. It is the tolerance I carried into everything after.

Later I ran current operations, which meant I set the squadron's daily flying. On deployment that was about 48 aircraft across six types, roughly $2B worth, spread over three ships and outside bases; in garrison it was smaller, about a dozen aircraft of one type. The hard part was never the flying. It was the scarce shared resources: competing Navy and Marine Corps priorities, ship positioning and flight-deck access, which Marines had to move and when, and constant re-planning as aircraft broke or readiness changed.

That is resource allocation under uncertainty, the same core problem as running a company's capacity or a portfolio, just with louder failure modes. It taught me that operations is mostly triage, done well, over and over.

I inherited a paper green book that ran every IT and comms request for a 250-person organization. I replaced it with a real ticketing system I built in Microsoft Access. The database wasn't really the point. What mattered was what it let me do: every request now had a status, and everyone who filed one got told exactly where theirs stood. IT stopped being a black box you dropped a request into and hoped.

The other fix was physical. Pilots planned missions on a shared network in one room, then carried the plan about 300 feet down the hall to brief it. That briefing room is also where the duty officer sits, the pilot running the day's flying, who is not allowed to leave the post. That person is almost always flying the next day and needs to prepare, and couldn't, because the planning network was in the other room.

I'd earned the CompTIA Network+ certification that none of my peers bothered with, so I knew how far I could run a single length of CAT5 without a repeater. I ran exactly that far, straight to the duty desk, and dropped a computer in. Now the person pinned to the post could plan during the downtime the job forced on them. It gave back something like 500 hours of planning time, and it wasn't complicated. It just took noticing.

Near the end of my time in the Marine Corps, I was sent to Saudi Arabia to help pull off an unusual port visit. Four US warships, led by a large amphibious ship, were coming into Jeddah Islamic Port. It had been about a decade since a comparable visit, and this time the ships were using one of the region's big civilian commercial ports instead of a naval base. I got there after the decision had already been made. My job was to make it real.

A naval base knows how to receive a warship. A commercial port has a different job, so ordinary questions suddenly needed answers: where do the ships go, who's allowed into the port, how do hundreds of American personnel move through a civilian facility, who provides what the ships need alongside, which Saudi organizations need access, and who actually has authority over each piece. Most of the work was finding the one person who could answer a question, making sure they understood what everyone else needed, and connecting the pieces.

One of my jobs was confirming that Saudi Arabia had formally cleared the ships into its territorial waters. As the arrival got closer, the Americans kept asking me the same thing: are we cleared? I asked a senior Saudi civilian official, and he thought the Navy had it. I asked the senior Saudi naval side, and they thought the civilian side had it. The ships kept getting closer.

A lot of it was expectations that didn't line up. The American side had its own sense of how fast a clearance should come and when the answer should exist, and it kept projecting that timeline onto a partner nation that didn't run on it. Add a handful of stakeholders who weren't talking directly to each other, and the calls all landed on me. Most of the work was managing that: explaining the same uncomfortable thing to the Americans, that this was Saudi Arabia's country and Saudi Arabia's call, while working the Saudi side to find the right people and make sure the request wasn't sitting forgotten on a desk. I could keep it moving. I couldn't manufacture a clearance nobody had issued yet. We got it in on time, but it was close.

Arrival wasn't the finish line. The busiest stretch started once the ship was alongside: hundreds of American personnel moving through a civilian facility, Saudi hosts coming aboard, and problems that needed an answer on the spot, now that everyone was finally in the same place. One of them:

The ship's security team planned a very intensive screening for anyone approaching the vessel. From their side, that was reasonable. Then I pictured our Saudi hosts going through it, and asked my translator whether it would be appropriate. His answer was essentially: absolutely not. The Saudis had welcomed an American warship into their port, and putting senior hosts through that kind of screening could turn a good visit into an insult.

The security team couldn't take that direction from me, but the captain could. So I called the captain, explained it, and asked him to change the procedure before the hosts arrived. He did.

A photo of the ship alongside in Jeddah is the simple version of the story. The real one is weeks of meetings, phone calls, unanswered questions, introductions, permissions, contractors, and reading the room across cultures and organizations, most of it once everyone was finally in the same place and needing something. Getting the ship there mattered. Keeping the visit running once it arrived was the bigger part of the job.