Pasadena and San Gabriel ValleyTech Guide for App Founders 2026

"If I leave the lab and build the app myself, am I the fortieth person this month trying the same thing?"

That's roughly what a founder asked me on a call this year. He had spent years on flight software, had a product idea that used what he knew, and had watched colleagues pack their desks in three separate rounds of cuts. He wanted to know whether Pasadena was a place to start something, or a place people were leaving.

My answer was both, and that the two facts are connected. A research town that sheds skilled engineers is also a town full of people who can build hard things and suddenly have time to do it.

This guide is the long version of that call. It covers Caltech and how its technology transfer office works, JPL and what actually happened to its workforce from 2024 to 2026, the spinouts I could tie to a primary source, the incubators I could confirm are still running, how you get around, and what an app costs if you build it here.

I checked every local fact live on September 30, 2026. Where a number circulates that I couldn't trace, I say so and leave it out. To be clear about my stake: I run Frenchy Digital, a Los Angeles app and AI agency, so I have an interest in "hire a local partner." I'll show you where that's the wrong call.

Pasadena is a separate city from Los Angeles, northeast of downtown, and it anchors the western end of the San Gabriel Valley. The valley runs east through cities like Arcadia, Monrovia, Azusa and Glendora out to Pomona.

The wrong model is to treat this as a smaller Silicon Beach. It isn't. The west side grew around consumer internet, media and games. Pasadena grew around a research university and a NASA lab.

The right model is a research park with a city around it. Think of a teaching hospital: the patients, the doctors and the equipment are world class, but the gift shop isn't where the action is. Here the action is in labs, licenses and engineers, and the app economy sits on top of that.

Therefore the question for you is not whether Pasadena has a startup scene. It's whether your product benefits from what this particular scene is good at. If your app is a camera filter or a dating feed, probably not much. If your app is the front end for a sensor, a model, a lab test or an engineering workflow, quite a lot.

If you're still weighing where in the region to build, our wider Los Angeles app development page covers how we work across the city, and the sibling guide to Culver City and Playa Vista describes a very different kind of cluster.

JPL is the biggest technical employer in this story, and the most misreported. So I went round by round.

JPL is managed by Caltech and is NASA's only federally funded research and development center, on a 168-acre site in the San Gabriel foothills near Pasadena (NASA JPL). Its own page still says about 5,500 employees and on-site subcontractors work there. Hold that number, because it's probably out of date.

The February 2024 round came amid uncertainty over Mars Sample Return funding, and the director at the time, Laurie Leshin, said the lab had already been cutting costs through a hiring freeze, reduced contracts and fewer on-site contractors (ABC7). The November 2024 round took about 325 more people and was expected to leave about 5,500 regular employees (ABC7).

Then in October 2025, JPL announced roughly 550 more, about 11% of the lab, as part of a reorganization that began that July. Director Dave Gallagher said the cuts were unrelated to the federal shutdown happening at the time (Astronomy). Physics World reported the lab would end up around 4,500 employees, down from about 6,500 at the start of 2024 (Physics World).

Let's do that arithmetic out loud. 530 plus 325 plus 550 is about 1,405 announced layoffs in under two years. The drop from about 6,500 to about 4,500 is about 2,000, so the rest came from attrition, retirements and other departures. Either way, something like three in ten jobs at the lab went away between January 2024 and the end of 2025.

What does this mean for you? Two things, and neither is "JPL is collapsing."

First, the funding cliff that people feared for 2026 didn't arrive, so the lab is not about to vanish. Second, the jobs already cut are not coming back quickly. Hundreds of experienced engineers who used to be locked inside a federal lab are now consultants, founders or open to offers.

I'm not going to tell you how many of them started companies. Nobody publishes that, and I won't guess.

Every Pasadena guide lists "JPL spinoffs." Most of the lists are loose: a founder once worked at JPL, so the company becomes a spinoff. I held a stricter line. A company only appears here if a primary or reputable source ties it to a Caltech or JPL license or program.

Why does a camera chip matter in an app guide? Because every photo feature you'll ever build runs on it. The most important mobile hardware story to come out of Pasadena didn't start as an app. It started as a license.

The pattern is clear. Caltech and JPL spinouts are hardware, biology, materials and robotics. The software surface on top of them (the dashboard, the clinician app, the fleet console) is where an app builder fits. That's the opportunity, and it's the frame for the rest of this guide.

Caltech's Office of Technology Transfer and Corporate Partnerships, OTTCP for short, is the door for both campus and JPL inventions. It files patents, negotiates licenses and helps form companies around them.

Its site lists the programs it currently points founders to: the Rothenberg Innovation Initiative, the Gates Grubstake Fund, the Gates Investment Fund, the Caltech Innovation Center, the Timothy D. Ryan Summer Entrepreneurship Program, the Bill Gross Prize for Entrepreneurship and OTTCP summer internships (Caltech OTTCP). It no longer shows a startup count on the page I loaded, so I don't print one.

The office also has two Entrepreneurs in Residence, one for physical sciences and one for life sciences, according to Caltech Magazine (Caltech Magazine).

Here's the misconception I hear most. Founders assume that because Caltech is down the street, it's a funding source for their app. For an outside founder with a consumer app, it almost never is. The programs are built for Caltech people and Caltech inventions.

The useful move is narrower. If your product needs a specific capability (a sensor method, an algorithm, a materials process) search for a Caltech or JPL invention that provides it and ask OTTCP about licensing. Expect negotiation over fees, royalties or equity, and expect months, not weeks.

That last point matters. Caltech itself is saying that its companies have tended to leave. If your plan depends on a Pasadena lab bench, the Green Street building is years from helping you. If your company is software, you never needed the bench.

Incubator lists go stale faster than anything else in this genre. I only kept programs whose own pages or recent local reporting showed them operating in 2025 or 2026.

What about the rest of the valley? I looked for primary evidence of dedicated tech programs in Arcadia, Alhambra and Monrovia and didn't find anything I'd stake a recommendation on. That doesn't mean nothing exists. It means I couldn't verify it, so it's not here.

Here's the borrowed idea I keep coming back to. Ecologists call it a forest gap: when a big tree falls, light reaches the floor and a burst of new growth follows. The fallen tree is a loss. The gap is an opening.

JPL's cuts are that kind of gap. About 1,400 announced layoffs in under two years put engineers into the local market who know testing discipline, safety-critical software and how to work with hardware. Those are exactly the skills a deep tech app needs and a typical consumer developer lacks.

The downside, stated plainly: flight software is not mobile software. Someone who wrote code for a spacecraft may never have shipped to the App Store, fought with push notification certificates or tuned an onboarding funnel. Treat that as a skills gap to fill, not a reason to pass.

For context on cost, the US Bureau of Labor Statistics reported about 58,450 software developers in the Los Angeles metro in May 2023, at an annual mean wage of about $151,780 (BLS OEWS). That's salary before benefits, taxes and equipment, and it covers the whole metro, not Pasadena specifically.

The mix I'd suggest for most founders here: keep the domain expertise in-house (that's your moat) and bring in a partner for the mobile and web layer, which is the part local science talent is least likely to have shipped before. We write about that split in full-time versus contract app developers in LA.

The most common founding team I see forming here is one deep technical founder, often from a lab, plus an outside partner for the app. That pairing works well when the handoff between them is designed, and badly when it's left to goodwill.

The wrong model is "the scientist owns the science and the agency owns the app." It sounds tidy. In practice the two halves meet at the data, and nobody owns the seam. Readings arrive in a format the app didn't expect, an alert fires at the wrong threshold, and each side assumes the other will fix it.

The right model is a relay race. What matters most is not how fast each runner is but the twenty meters where the baton changes hands. Teams that win relays practice the exchange zone more than the sprint. For a deep tech app, the exchange zone is the data contract.

Writing that document usually takes a day or two inside discovery. It saves weeks later, because most of the scope arguments I see on companion apps are really arguments about data nobody wrote down.

Now the arithmetic on who should do what. Using the BLS metro mean of about $151,780 a year from the talent section, one developer costs roughly $12,650 a month in salary alone, before benefits. Using our published senior rate of $150 to $225 an hour, a partner costs $6,000 to $9,000 for a 40 hour week. So a month of partner time at full load is roughly $24,000 to $36,000, which is about two to three times a salaried developer's monthly pay.

That sounds like a case for hiring. It isn't, for a first version, for two reasons. The partner brings design, mobile, backend and QA in that price, which one hire can't. And the partner stops costing money when the phase ends, while a salary keeps running whether the pilot works or not. The case for hiring arrives later, once the app has users and needs weekly changes for years. At that point, a former lab engineer who already knows your data is often the right first hire, and the handover documentation from the build is what makes that hire productive in weeks rather than months.

One downside to name. A partner who doesn't understand your domain will build exactly what the contract says, including the mistakes in it. The fix isn't a smarter partner. It's the founder reviewing every weekly demo against real device data, not a mock file. That costs you an hour a week, and it is the cheapest quality control in this whole plan.

The practical stuff is where founders here lose the most time, so let me be concrete.

On meetings: the wrong model says a local partner means a weekly commute. The better model is three to five in-person sessions over a build (kickoff, a design review, launch readiness, a post-launch review) and remote everything else.

That hardware test row is the Pasadena specific one. If your app pairs with a sensor or lab instrument, a partner you can put in the same room as the device saves you a surprising amount of back and forth.

So which apps should a founder actually build out of Pasadena? I sort them by how much they draw on what the area is good at.

The pattern in that table is simple. The closer the app sits to a hard, physical or scientific problem, the more Pasadena helps. The closer it sits to attention and virality, the less it does.

This isn't a rule that consumer founders can't live here. Plenty do, and the rent can be friendlier than on the coast. It's a statement about where the local network gives you an unfair advantage and where it gives you nothing special.

For the strong-fit categories, a few design decisions come up again and again. Is the phone talking to the device directly over Bluetooth, or through the cloud? What happens when the factory, lab or field site has no signal? Who is allowed to see which readings? Each of those answers moves the cost more than the number of screens does.

My rule of thumb is to answer those three questions in writing before any partner gives you a price. A quote that arrives before anyone has asked about offline mode is a quote that will change.

And one more honest note for science founders. Your first users will forgive an ugly interface if the data is right, and they will abandon a beautiful one the first time a reading is wrong. So spend the early budget on data correctness, sync and alerts, and let polish wait for the second release. That order feels backwards to most designers. For this audience it's the right one.

I'll only print our own published ranges. Anyone quoting you an "average app cost" for Pasadena is quoting an agency sales page, and I haven't found one with a method behind it.

The MVP tiers and their timelines are on our MVP development page, with a discovery workshop of 3 to 5 days, rapid prototyping of 1 to 2 weeks, a lean development sprint of 3 to 6 weeks and a launch of 3 to 5 days. If your app includes a model, classifier or agent, our AI development work covers that layer.

What pushes a Pasadena app toward the top of a band? In my experience it's integration, not screens. A companion app that talks to a device over Bluetooth, streams sensor data or has to meet a lab's data rules costs more than a booking app with the same number of screens.

What keeps you at the bottom? Treating the app as a window, not a product. Show the data, let the user act on it, and leave the analytics suite for version two.

If you're weighing a local team against a remote or offshore one on price, our comparison of Los Angeles versus offshore app development cost works through it with the same refusal rules as this piece.

A worked scenario, clearly labelled: this is illustrative, not a client story, and every price comes from our published bands above.

Suppose a founder who left JPL in the October 2025 round has licensed a sensing method and built a working hardware prototype that monitors equipment vibration in small factories. Customers want to see readings on a phone and get an alert when something drifts. The founder has about $100,000 for everything software until a seed round.

Add it up: $14,000 plus $45,000 plus four months of retainer at $2,500 ($10,000) is $69,000. That leaves $31,000 of the $100,000 for cloud costs, a second hardware batch and surprises. Put another way, the app takes about 0.69x of the software budget, and the founder keeps about 0.31x in reserve.

Now the in-house comparison. At the BLS metro mean of about $151,780, $69,000 buys roughly 5.5 months of one developer's salary before benefits. One developer in five and a half months can build this, maybe, if they already know mobile, cloud and push. Most former flight software engineers would be learning two of those three on the job.

The risk in the plan is the founder's own expertise. Scientists want the app to show everything the sensor can measure. If the scope reopens in week seven to add a spectral chart and an AI anomaly detector, the $45,000 becomes $75,000 and the reserve is gone. So the proposal writes version one as "readings and alerts," and everything else goes on a list for after the pilot.

I want to be precise about our own evidence. We don't have a published Pasadena deep tech case study, and I won't invent one.

The closest thing I'd point to is LA Pro Security, a Los Angeles security company. It's a website, not a native app. We built an instant quote calculator, service scheduling, a client portal and a real-time guard dispatch dashboard for managing assignments, shifts and locations.

Why is that relevant here? Because the dispatch dashboard is the same shape as most deep tech companion apps: live status from the field, a list of assets, and someone who needs to act when something changes. The domain differs. The architecture problem doesn't.

The terms matter as much as the build. We've been operating since 2016, as a US company since 2019. Full source code and IP transfer to the client, there's a 30-day post-launch warranty, and we send a fixed-price phased proposal within 5 business days. For a founder holding a Caltech license, clean IP ownership of the app layer is not a nice extra. It's something investors will ask about.

If you want a neutral list to compare us against, our round-one ranking of the top app development companies in Los Angeles scores agencies on things you can check yourself.

Here's where I argue against my own advice. Four things go wrong most often for founders in this part of LA.

Why is the plan still right despite these? Because each downside is bounded. A fixed-price phase caps what one stage can cost, the 0.31x reserve absorbs a bad pilot, and owned code means you can switch partners. The alternative, hiring a full team before the device works, has no cap at all.

A handful of Pasadena figures appear everywhere. I chased each one and couldn't make it hold as independent fact.

• "Caltech has launched over 240 startups, 25% with exits and 40% still active." This comes from a Caltech article published in January 2017. It is nearly a decade old and self-reported.
• Larger Caltech totals for startups since 1990 and capital raised. I saw them only in search snippets, not on the page I fetched, and they are self-reported.
• "More than 120 CMOS imagers produced every second." Attributed to a market research firm through secondary coverage. NASA Spinoff's figure, more than a billion sensors a year by 2013, is the one I use.
• Idealab's company and exit totals, and the Pasadena BioCollaborative Incubator's 100 companies. Printed here only as the organizations' own counts.
• The contractor count in JPL's February 2024 layoffs. One report says 40 contractors and another summary says 140, so I print neither.
• How many laid-off JPL staff started companies. No one publishes it.
• Any Pasadena startup count, venture total or "average app cost." Every version I found lacked a dataset or came from a vendor.

I also couldn't confirm whether the Wilson Hill partnership is still investing in 2026, or verify dedicated tech programs in Arcadia, Alhambra or Monrovia. And JPL's own site still shows about 5,500 people while reporting after the October 2025 cuts points to about 4,500, so treat the official page as possibly out of date.

Back to the engineer on the call. He didn't quit to build an app. He decided to build the device first and scope the app as a window onto it. Here's the same short list for you.

• Write one sentence on what your app shows and what the user does with it. If it takes a paragraph, the scope is too big for an MVP.
• If your product rests on a Caltech or JPL invention, email the tech transfer office about that specific invention, and apply for your Pasadena business license.
• Book one in-person discovery session with a build partner, ask for a fixed-price phased proposal, and get code and IP ownership in writing.

If you want us in the comparison, book a call at calendly.com/frenchydigital/discovery-call. And if you're planning around a demo day, our 12-week LA app timeline shows what fits and what doesn't.

Time to build.