The stack

• Expo and React Native for the client

• EAS for builds and OTA updates

• Clerk for auth

• Neon for serverless Postgres

• Drizzle as the ORM, shared between mobile and the Next.js backend

• Next.js on Vercel for landing pages, public entry pages, OG images, cron-driven endpoints

• Cloudflare R2 for image storage

• Expo Push for notifications

The mobile app and the Next.js backend point at the same Neon database, and they both import the same drizzle/schema.ts file. That is the whole code-sharing story, and it has been completely fine.

The dial-in

After a few updates I stopped thinking of the mobile app as an app and started treating it as another deploy target. These are the pieces that got it there.

• Local EAS builds. eas build --local is free, runs on my MacBook, takes minutes for both platforms, and never queues. The first thing every Expo tutorial tells you to do is use the cloud build service. The second thing you should do is stop.

• OTA updates for JavaScript-only changes. If a change does not touch a permission, a plugin or the version number, it ships over the air in about sixty seconds. The first time you hear about OTA you assume it is only for fixing typos. It is also how I have shipped entire new features, screen redesigns and bug fixes between store reviews, which is most of the work I have done on this app since launch.

• Pushed Vercel to its limits. Same repo handles the landing page, public entry pages, OG images, push-notify endpoints, and three cron jobs (daily backup to R2, weekly recap, daily lookback). The whole thing is one deploy on the free tier and zero servers for me to feel guilty about. But I suspect that I’m definitley abusing it.

How I used AI beyond writing code

This is the bit I keep wanting to talk about and nobody ever asks.

1. Mobile dev as a guided tour. On day one I knew nothing about Apple Developer accounts, EAS, Expo Go versus dev builds, code signing, magic-link redirect URLs, or why my iOS simulator was rejecting an OTP. By the end of that same day I had a preview build on my phone. I was rude to the agent at one point. I would quote myself but I am hoping my mother does not read this.

2. No experience, no problem. Push notifications on iOS that carry images require a small piece of Objective-C in something called a Notification Service Extension. I have never written Objective-C in my life. AI produced the whole thing in one shot, and I have no plans to ever learn what any of it says.

3. The paperwork to actually reach production. The headache of getting an app to production is not the code. It is the paperwork on top of the code, and Apple and Google operate so differently that you cannot apply lessons from one to the other. Two examples that cost me weeks each:

• Apple rejected my first TestFlight submission with the phrase “Guideline 2.1 - Information Needed.” Translated: the reviewer opened the app, saw a passwordless email-magic-link sign-in, and could not get past it because they do not own the test email. The fix was either to hand the reviewer an email account they could log into (which now means handing over 2FA codes as well) or to add a password-based login as a second auth mode purely for the review team. I went with option two. Before I could resubmit, I built a “Password” tab into the sign-in screen with a username and password for the reviewer, wrote a Beta App Description for App Store Connect, a separate set of Review Notes explaining how to use the password tab, and a third “What to Test” message for the human beta testers, all of which Apple stores in different places inside the same console. Cursor wrote first drafts for all three.

• Google Play makes you fill in a production application before you can leave closed testing. The catch they bury in the small print is that a closed test requires twelve testers active for fourteen days, and real friends and family alone will not get you there. I paid for testers. The application itself is seven free-text questions about recruitment, feedback, the value the app provides to users, and how you know it is ready, each capped at three hundred characters. I pasted the questions into Cursor along with my own documentation and had passable first drafts in thirty seconds. The hardest part of that conversation was me asking whether I could just say friends and family and quietly skip the paid testers. The agent talked me out of it.

The two stores have almost nothing to do with each other, and neither tells you in advance which paperwork to start preparing. AI turned each individual step in that gauntlet from an afternoon of research into thirty seconds of paste-and-edit.

Costs

Apple Developer: $99 / year
Google Play: $25 one-time
Cloudflare R2 (3 GB across 50 weekly actives): effectively $0
Neon Postgres: free tier
Vercel: free tier
EAS: free tier
Clerk: $20 / month

I think its pretty incredible that I was able to ship a social media application to both app stores in under a year, let alone a single month. Hopefully this articles helps you with your dev process!

Here's what I wish someone had told me as a CS freshman.

Find Your Drive First

Most students approach CS backwards. They focus on getting the job, securing their future, and checking boxes. That's fine, but it's not exciting. And it won't make you exceptional.

I discovered this by accident. As a mechanical engineering student, I wandered into a hackathon and saw students building incredible things – mobile apps that tracked nutrition, interactive dance machines, and programmable robots. What struck me wasn't just what they built, but how quickly they could bring ideas to life. In mechanical engineering, it took months to go from idea to physical product. That’s why I pivoted from Mechanical Engineering to Computer Engineering in my sophomore year. With software, you could build something useful in days.

This is what should drive you: the ability to take any idea and make it real.

Pick One Thing and Stick to It

Here's the plan I wish every CS freshman would follow:

1. Choose something you're genuinely interested in. Love tea? Build a tea review platform. Obsessed with fantasy football? Create a stats analyzer. Passionate about music? Build a playlist generator.

2. Commit to it for two years. Yes, two years. Here's how:

   • Work in six-week cycles

   • Plan what you'll build in each cycle

   • Stick to the plan during the cycle

   • Take a week to reflect and plan the next cycle

   • Repeat

This sounds simple. It isn't. Your project will evolve. You'll need to add pagination when your data grows. You'll want a mobile app. You'll realize you need better performance. You'll integrate machine learning as you learn it in class.

This is the point. Real software engineering isn't about writing neat, isolated projects. It's about building something that grows, evolves, and becomes more complex over time. Two years of consistent work on one project will teach you more than dozens of abandoned weekend projects.

The Numbers Game of Getting Hired

Now for the tactical stuff. Here are the brutal numbers I've seen work:

• 100 online applications → 2 interviews

• 10 interviews → 1 final round

• 3 final rounds → 1 offer

But here's the hack: In-person connections change everything. Three conversations at a career fair can get you an interview faster than 100 online applications.

From day one of freshman year:

1. Mark every career fair date on your calendar

2. Track which companies are coming to campus

3. Attend every tech talk and networking event

4. Go to hackathons – both on and off campus

5. Document your journey publicly on Twitter and LinkedIn

Don't worry if your early posts are rough. They will be. The point is building the habit.

The Ideal Internship Progression

If you execute this well, here's your optimal path:

1. Freshman Year: Any software internship. Local IT company? Perfect.

2. Sophomore Year: High-growth Series C+ startup.

3. Junior Year: Big Tech. They hire juniors in the hopes to convert them fulltime.

This progression lets you experience different environments and make an informed decision about your first full-time role. Big Tech offers great compensation. Startups offer accelerated learning. A late-stage startup can offer both.

A Final Note

This might seem like a lot. It is. But here's the secret: most students won't do this. They'll bounce between tutorial projects, cram leetcode before interviews, and hope for the best.

You don't have to do everything perfectly. But if you pick one thing you care about, build it consistently for two years, and approach the job search systematically, you'll be ahead of 95% of your peers.

And more importantly, you'll actually enjoy the journey.

1. Scaling hardware orchestration (it’s an AI company) to keep up with demand.

2. Creating a solid foundation for the product to make adding features easier.

Here is my advice:

Don’t Call the Role “CTO”

The person you want to hire will still spend most of their time coding. In rapidly growing companies, architectures change dramatically. Until you have over 100 engineers, you don’t need full standardization (I saw this firsthand at Ridgeline). You need someone who can:

• move fast

• not be tied to their decisions

• and implement these architectures hands-on

Call the role “Staff/Principal Engineer” and add a significant equity component so they almost operate like a technical founder. This role should be a direct path to CTO if they choose.

Hire for Low Ego

A CTO title adds unnecessary ego to your startup. You need someone who prioritizes speed over perfection. Simple architectures are better for rapid growth.

Hiring someone with low ego is crucial because:

• Decision Making: The decisions they make should prioritize rapid progress over perfect solutions. Startups thrive on quick iterations and learning from mistakes rather than spending weeks to make the perfect choice.

• Team Dynamics: Low ego individuals tend to foster a collaborative environment. They are more likely to listen to other team members, welcome feedback, and make adjustments based on collective insights. This is essential in a small, fast-moving team where every member’s contribution is vital.

This is especially important because, like it or not, you'll project this person’s characteristics onto the next hires. Do you want five more engineers like them? They’ll likely lean towards hiring friends or past colleagues. This can be a good thing if you build a team of low-ego, high-output engineers.

How do they spend their time now?

Most of their time should be spent coding, prototyping, and unblocking other engineers. They are the first ones addressing customer feedback/ issues without being asked to. A very minor part of their job involves recurring meetings. Ideally they spend less than 4 hours a week in meetings.

Red Flags 🚩

These are some red flags I've seen with early stage technical leaders:

1. When you describe a complicated problem, they immediately offer a solution without seeking to understand.

2. They propose using something like AWS Amplify, unless it’s specifically for prototyping.

3. They want to rebuild fundamental technology to solve a problem (like an ORM, graph database, programming language, query language, etc.).

4. They don't ask about the customer or use the product to understand their pain points.

5. They aren't able to work fullstack/ refuse to do so.

6. They don't have experience writing documentation or explaining complex topics to non-technical people.

Be Prepared to Fire Early

The best companies make decisive hiring and firing decisions. If someone isn’t a culture fit, isn’t pulling their weight, or seems absent, consider letting them go. It’s not a reflection on the person—they might be incredible but not the right fit at this time.

Conclusion

I don't think CTOs build companies at early stages, engineers do. When are you hiring, be very choosy, but if the right person comes along, close immediately.

• Will Larson dissects the path to staff engineer

• Gergely Orosz deconstructs engineering leadership

• Countless newsletters analyze every move at FAANG

But startups? Radio silence.

This gap matters. Startup engineering isn't just scaled-down big tech. It's a unique beast with its own rules, challenges, and success metrics.

My Journey

I've spent my career in startups:

• Founding engineer and tech lead at Ridgeline (from pre-seed to Series C)

• Incubator founding engineering at Atomic (with 1 exit)

• Part of the kickass engineering team by Ironfish (backed by a16z and Sequoia)

• Big tech stint at Microsoft

Here's what I've learned: most startup engineering advice is wrong. Or at least, dangerously incomplete.

It doesn't tell you:

• How to be the entire "platform team" at a 10-person company

• How to ship a critical feature in a week because your CEO is pitching investors

• What to do when you suddenly become a part-time product manager

The Hidden Realities of Startup Life

But that's just the technical side. What about everything else? Here's what no one tells you:

1. How to evaluate a startup offer

2. How stock options really work

3. Why the 10th engineer often ends up better off than the 1st

4. The reality of 80-hour weeks

5. The mental toll of constant context-switching

6. The emotional rollercoaster of missed deadlines and pivots

7. How to decide if startup life is even right for you

8. What makes the mythical 10x engineer “10x”/ “cracked”?

Why This Blog Exists

That's why I'm writing this blog. To fill the gaping hole in startup engineering advice. To share the truths I wish I'd known a decade ago. Here's What You'll Get:

1. War stories from the startup trenches

2. Practical strategies for navigating hypergrowth

3. Insights on building engineering teams from scratch

4. Honest comparisons between startup and big tech life

5. Techniques for making critical decisions with limited information

6. Real talk about startup compensation, equity, and career trajectories

7. Frameworks for evaluating startup opportunities

8. Strategies for maintaining sanity in the chaos

9. Data-driven analysis of what really makes a 10x engineer

Who Will Benefit From This?

This blog is designed to provide value for a wide range of tech professionals, especially those interested in or already involved in the startup world:

• College Grads and Early Career Engineers: Get a head start understanding the unique challenges and opportunities in startup engineering.

• Big Tech Engineers: Gain insights into how startup engineering differs from big tech, whether you're curious or considering a change.

• Aspiring startup CTOs: Learn the ropes of technical leadership in a startup environment.

• Non-Technical Founders: Understand the engineering side of your startup better, improving your ability to work with and hire technical talent.

• Anyone Curious About Startup Engineering: Whether you're actively job hunting or just exploring options, you'll find valuable insights here.

🚀 Attention Founders: This is for You Too

You're not off the hook. In fact, you might need this more than anyone. Here's what you're probably asking yourself right now:

1. When do I need to hire a CTO? Or should I be the CTO?

2. How do I know if my engineering team is actually performing well?

3. What should my engineering culture look like? How do I shape it?

4. Am I technical enough to lead this company?

5. How do I hire engineers when I can't match Big Tech salaries?

6. When should I start worrying about tech debt?

7. How do I know if we're building the right thing?

8. How do I identify and attract 10x engineers to my startup?

These aren't just engineering questions. They're existential ones for your startup. Get them wrong, and no amount of product-market fit will save you.

I'll tackle these head-on. No BS, no fluff. Just hard-earned insights from years in the trenches.

The Bottom Line

Fair warning: startup life is brutal. The lows are lower than you expect. But the highs? They're unlike anything else.

My goal is to help you navigate this terrain and decide if it's right for you.

> Welcome to the manual I wish I'd had. Welcome to Founding Engineer.