crawshaw
Come own and build a brand at a Series A startup.
Hopefully this helps mathematicians. It seems very clear to me that it will help software engineers apply formal methods to more of our software.
come build a cloud. we are doing everything from custom hardware to custom ssh servers to our own global load balancer. very senior small high-trust team looking for someone we can rely on to get done whatever is most important in the stack for the business. some days that means patch the vmm. other days it means figure out passkey quirks. more about what we are building here: https://crawshaw.io/blog/building-a-cloud email me at [email protected].
Come build a new cloud. The entire engineering team has been in the industry 20+ years. Lots of hard problems. The freedom and responsibility to do what you think matters, push it to prod and deal with support when it breaks.
We are all busy discovering the shape of new tools and norms as our profession has been overturned by LLMs. It is not too surprising similar ideas are floating about. Though I have not seen anything that captured how I now go about personalizing programs, and how I expect it to change our industry. So I wrote this.
FWIW the first version of meat was based on anthropic models, I switched to Oai models because they are faster and just as good right now. This is an astonishing thing to say, but the switch was a single shot prompt using a frontier model. I’m happy to add some selector there, but that is also the point of this article: do you really need me to make it configurable when you can switch the tool over to Anthropic with a single prompt? It’s a strange new world we live in.
On the website: you’re right. I have some side-by-side diff examples I want to turn into a website. I am just short on hours in the day. My real goal is to make the tool compelling enough that I can convince my colleagues that we should build it into Shelley. :)
(We have a fix for this coming in a few weeks.)
It’s a real tension, working with a remote dev env has never been my first choice. But agents seem to tip the balance enough in favor of remote that I have switched.
This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.
There is a good reason for this! In a large group of people, there are bad people.
This is also why I am done working at large companies. I learned a lot, met some great people, but am uninterested in a low trust environment. I like relying on my colleagues. When they do something unexpected, I am surprised and study it to learn, not lambast.
For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.
competitive salary, meaningful early equity, 2 days a week in the downtown sf office
come build a cloud. we are doing everything from custom hardware to custom ssh servers to our own global load balancer. very senior small high-trust team looking for someone we can rely on to get done whatever is most important in the stack for the business. some days that means patch the vmm. other days it means figure out passkey quirks.
more about what we are building here: https://crawshaw.io/blog/building-a-cloud email me at [email protected].
Our exe.dev web UI still runs on AWS. We also have a few users left on our VM hosts there, as when we launched in December we were considering building on AWS. Now almost all customer VMs are on other bare metal providers or machines we are racking ourselves. We built our own GLB with the help of another vendor's anycast network. You can see that if you try any of the exe.xyz names generated for user VMs.
We would move exe.dev too, but we have a few customers who are compliance sensitive going through it, so we need to get the compliance story right with our own hardware before we can. It is a little annoying being tied to AWS just for that, but very little of our traffic goes through them, so in practice it works.
I need to fix our transfer pricing. (In fact I'm going to go look at it now.) I set that number when we launched in December, and we were still considering building on top of AWS, so we put a conservative limit based on what wouldn't break the bank on AWS. Now that we are doing our own thing, we can be far more reasonable.
Almost every VC rejected us when we went to get seed funding for Tailscale, we knew none of them. Friends of friends of acquaintances got us meetings. Fundraising is very possible for you if you are committed to building a business. Most important thing is don't think of fundraising as the goal, it is just a tool for building a business. (And some businesses don't need VC funding to work. Some do.)
The biggest challenge is personal: do you want to build a business or do you want to work with cool tech? Sometimes those goals are aligned, but usually they are not. Threading the needle and doing both is difficult, and you always have to prioritize the business because you have to make payroll.