In the fast-paced environment of a startup with fewer than 30 engineers, traditional departmental boundaries dissolve. Engineers don't just write code—they become the face of the company, directly engaging with customers who are often the first to discover and shape the product. This unique dynamic creates what might be called 'larval stage' support engineering, where technical expertise meets customer service in ways that can determine a startup's trajectory.

At Modal, a company with a strong customer-focused culture, all engineers talk to users directly. The team strives to reply instantly, sometimes at 1:36AM in the morning, and may even get on planes to meet customers the same day. This commitment to customer obsession isn't just a nice-to-have—it's a fundamental business strategy that has served them well for over three years.

Article illustration 1

Slack waiting for response - the danger of internal discussions without customer communication

The Three Core Mantras of Early Support Success

After years of refining their approach, the Modal team distilled their support philosophy into three core principles that form the foundation of their customer relationships:

  1. Reply to the customer
  2. Get on a call
  3. Follow up fast

These mantras, while seemingly simple, address critical pitfalls in startup customer support and represent a fundamental shift in how engineers approach their work.

The #1 Rule: Reply to the Customer

This principle is so fundamental that it motivated the author to write about customer support for the first time. As Modal grew beyond fifteen engineers, a concerning pattern emerged: engineers would spend hours swarming on support issues in internal channels, exchanging theories and debugging information—without ever messaging the customer.

Article illustration 2

Akshat Support - the human element of technical assistance

A particularly interesting technical issue can function as a "nerd snipe," capturing the attention of multiple engineers who engage in extensive internal discussions while the customer remains left on read. The customer, unaware of the intense activity behind the scenes, might reasonably conclude they're being ignored.

Another failure mode occurs when an engineer works diligently on a problem for hours, only to close their laptop at the end of the day without updating the customer. From the customer's perspective, especially with time-sensitive issues, this can feel like abandonment.

The solution is straightforward yet requires a mental shift: engineers must prioritize regular customer updates. "To start improving as support engineers at a startup an engineer needs to start mentally putting the user first. User first, technical investigations second," the author explains.

Get on a Call

While some engineers naturally energize from customer interactions, many—including the author—don't. This reluctance makes getting on calls a non-default behavior that requires regular affirmation despite its high value.

The author notes that in Modal's early days, engineers repeatedly got on calls with customers, establishing it as standard practice. "If a back-and-forth with a customer just isn't getting the issue squashed, get on a call. If a customer is complaining, get on a call. If you need to sell a feature—if you need to sell the whole product—get on a call. If there was an outage and the customer is pissed, get on a call and show them you care, listen to their pain."

Article illustration 3

Bezos customer obsession - the principle that drives startup success

This aligns with Paul Graham's famous "Do Things That Don't Scale" essay, which advises founders to engage directly with customers even when it seems inefficient. "Getting on calls is hard work, it's social labour. You have to turn off Spotify, move away from your desk. You have to be on, for at least twenty minutes. It's possible you won't understand their problem, or their code. Maybe so. But startups must show up for their customers. Startup engineers must get on a call."

Follow Up Fast

The third mantra addresses response speed with an important caveat. While engineers shouldn't become distracted by maximizing response times at the expense of quality, there's a massive difference between replying in 30 seconds versus 30 minutes.

The author references Sam Altman's observation about response times: "I wrote a little program to look at this, like how quickly our best founders—the founders that run billion-plus companies—answer my emails versus our bad founders. ... I don't remember the exact data, but it was mind-blowingly different. It was a difference of minutes versus days on average response times."

Lightning-fast replies delight customers in several ways:
- They feel they have close attention and matter
- They perceive the product as actively maintained and evolving
- The feedback loop feels interactive and responsive
- The team appears highly competent and intimately familiar with both customers and product

"Fast follow ups are infectious and energizing. The speed of feedback and evolution in a startup is one of the best reasons to participate in them," the author notes, sharing a customer sentiment: "'we feel like you are a team at our company' 'we feel like we're your only customer' 🥹 exactly how we want our customers to feel ❤️"

The key is balancing speed with quality—avoiding rushed responses or constant distraction, while seizing opportunities to quickly answer questions or fix bugs. "Don't leave it for after lunch, or the next day," the author advises.

The Philosophy That Doesn't Scale

Much of this approach can be seen as applying Paul Graham's "Do Things That Don't Scale" specifically to customer support engineering. While Graham originally addressed founders, the principles apply equally to early startup employees who work in close proximity to founders maintaining an uncommon attention to users.

"Because the now old advice really is true: if you're customer obsessed, you have a good chance of winning," the author concludes. "A lot of the above is what you get when you take Paul Graham's famous Do Things That Don't Scale essay and apply it just to customer support engineering. That essay is advice for founders, but advice for founders applies pretty well to early startup employees. It's a principle advantage of being an early employee at a startup that you get work in close proximity to people (the founders) who are compelled into maintaining an uncommon, 'insanely great' attention to users and customer service."

In the end, these unwritten rules of startup support engineering represent more than just good customer service—they form a competitive advantage that builds loyalty, accelerates product development, and creates the kind of customer relationships that can propel a startup through its most vulnerable early stages.