Working at a YC Startup in SF

My summer at Automax AI

The only internship that I had before joining Automax was at Symcor, a company in the financial services sector. All I knew about the SDLC was sprints, tickets, story points, and a large number of people on each team handling development work, DevOps, QA, and so on. It required a great deal of effort and an excessive number of steps to get a small change from my laptop to production.

Then, I moved to Automax, an early-stage startup with around seven people when I joined.

On the first day, I was given access to the GitHub repositories, Azure, and unrestricted permissions that I believed no one would normally grant to an intern. There was no ticketing system, all the information was stored in Notion docs, and decisions that would have taken hours of sprint planning sessions at my previous company were reached during our daily standup. Each member of the team focused on a part of the product, such as the mobile app, DevOps, or ML research, and if there was something that needed to be done, the person who had the most capacity would take it on.

What I had expected going in was closing tickets, only at a much faster pace. Instead, during most of the summer, I owned an entire product, was given an open-ended problem to solve, and was then expected to produce a well-thought-out plan.

A crash course in appraisals

Automax builds software for real estate appraisers, an industry I knew nothing about.

Most appraisal software out there is terrible, and the user interfaces and overall user experience resemble old government websites that are incredibly hard to navigate. The workflows for completing an appraisal report are complicated and very tedious, as you have to manually fill in hundreds of boxes. By applying AI to accelerate certain parts of that workflow, Automax helps appraisers complete their reports more efficiently and with greater accuracy.

The fact that this startup had been established only in the past few months made the situation interesting, since the industry was transitioning to UAD 3.6, a new data standard featuring a redesigned report format. This meant all the appraisers had a great deal to relearn, and as a result we were rushing to develop software to race into the market. Clients (both lenders and appraisers) were waiting and calling endlessly, demos were continually being arranged, and we needed to have new features lined up to show at conferences. That sums up how a lot of the engineering was done within these startups.

Actually full stack

I worked all across the stack, engaging in different parts of the tech stack, and I did so by developing React user interfaces, backend services, AI features, working on DevOps, setting up the monorepo, and even redesigning the landing page. When we first started, shipping boiled down to making a pull request and merging it yourself into main. Later, we introduced some sort of review using tools such as Cursor Bugbot, but this was still far from the process I was used to.

The team consisted of engineers no more than three years older than I was, and they offered their help whenever they could. But there was a cost. As everybody was busy with their own projects, there was no structured mentorship like there was at Symcor. I was given a great deal of freedom, and to be honest, a lot of the time I didn't know what to do with it. That was the main adjustment I had to make when I joined.

How much is a house feature actually worth?

The most interesting project that I was involved in was an automated system that derived appraisal adjustments from market data.

When an appraiser is comparing a subject property with those that have recently sold (comparables), they need to take the differences into account. "How much should a given feature affect the price, and what evidence supports this?" I was surprised that some appraisers out there just used their instinct or selectively cherry-picked pairs of sales to support their proposition, but it generally differs from one appraiser to another. It felt like this entire system could be much more concrete and data-driven.

The system that I implemented was an ensemble that combined three methods: grouped paired-sales analysis, generalized additive model regression, and depreciated-cost estimates. I dealt with the paired-sales system in collaboration with Brent Bowen, who had extensive knowledge of appraisal and real estate economics. He developed a method involving an entire set of possible adjustments rather than arriving at a single fixed figure, and we refined it over and over again across a variety of markets and datasets.

My favourite part of this project was that I couldn't just give Claude Code a specification and have it return a working solution. It required a thorough understanding of appraisals in order to build it, asking actual appraisers how they arrive at their adjustments, running the system on messy real-world market data, and performing thorough testing with Brent to examine what went wrong. Working directly with a domain expert was something I'd never done before, and it really sped up the entire process.

Moving fast leaves a mess

It wasn't a walk in the park. The codebase was enormous (I think it had over 5 million lines of code), the naming conventions were inconsistent, and sometimes I would spend hours trying to work out where something had been deployed, only because of a poor naming choice. With any sort of future change, you first had to reverse-engineer the existing system, which was very frustrating as it was messy and there was a lack of documentation.

I don't blame them. I understand why this happens. If a customer requires something urgently or if a demo is due tomorrow, a hotfix deals with the problem at once, while a proper cleanup takes hours or even precious days that are needed elsewhere before the next deadline.

I left with a true appreciation for the boring parts, such as consistent naming, writing detailed documentation, style guides, and so on. These little things make a big difference when you're new to an industry like I was, working on a huge codebase with over 13 microservices, and having to deal with vague problems.

My thoughts on San Francisco

Nice weather. Very expensive.

Glad I got to experience it. Not planning to live there long term.

Would I do it again?

Yes.

I got to work through the entire stack, take ownership of real projects myself, learn about a completely new industry, and speak directly to the people who used the things that I had built. There was also a lot of confusion, messy code, and an unclear scope, but I believe that figuring things out as you go is something that happens when you're growing in any field.

I'm not sure who the audience for this writing is, but if you're considering joining or starting a startup, I hope my experience has informed you of what startup life could potentially be like.

From this little trip, I feel I've become more conscious of my shortcomings, experienced software development at a significantly different pace, and modified my engineering mindset for the better. I'm really excited to take what I've learnt and bring it along with me to my next internships!

A huge thank you to Humza, Sindri, Shadi, Brent, Mark, Bassam, and Dabeer for making this summer such a memorable one.