What nobody tells you about the nanosatellite electronics market

I was 21 when the boards stopped being school projects

I was 21 when I started doing real nanosatellite electronics work at TSC Technologies. Not the college version where a board works once, a camera comes out, and the system is declared finished before the solder has cooled. Real work meant subsystem boundaries, board bring-up, power rails, radio assumptions, validation notes, production handoff, and the uncomfortable discipline of proving that another engineer could understand what I had built.

The work sat across OBC, EPS, RF, telemetry, ADCS-support electronics, documentation, and test. The form factors mattered too: 0.3U, 1U, and 3U CubeSat buses. A 0.3U platform forces packaging discipline. A 1U bus forces the classic CubeSat trade among power, compute, RF, and payload room. A 3U bus gives more space and then tempts everyone to spend that space too quickly.

That period changed my taste in engineering. Before it, I liked clever architectures. After it, I cared more about the record that survived the architecture. What was tested? What failed first? Which rail came alive before the others? Which subsystem could be powered down without turning a small problem into a dead vehicle? Which document would help someone on a bad day when I was not in the room?

The answer to those questions is the real credential.

What a nanosatellite electronics team actually does

The public vocabulary around satellites starts with mission words: imaging, communications, IoT, weather, climate, defense, education. The electronics team lives underneath that. It asks whether the spacecraft has power, compute, command handling, telemetry, RF, fault behavior, and enough test access to make the work reviewable.

OBC means onboard computer. It has to hold command handling, local state, telemetry, sensor interfaces, and fault behavior together. EPS means electrical power system. It handles solar input, battery behavior, regulation, load switching, brownout response, and the hard question of which subsystem deserves power when the bus is stressed. RF is the communications path: UHF, VHF, 2.4 GHz, antennas, packet framing, noise, and the link assumptions that look innocent until the ground station matters. ADCS-support electronics sit around sensors and actuators that help the vehicle know and change its attitude.

None of this is glamorous in the moment. A lot of it is oscilloscopes, current limits, rework stations, board files, connector choices, BOM cleanup, missing pull-ups, ground strategy, and one sentence in a datasheet you should have taken more seriously. The algorithm is usually the fun part. The rest of the system is where the algorithm earns the right to run.

Small spacecraft work also teaches a useful kind of suspicion. If a subsystem works only when the original engineer is nearby, it is not done. If a board can be tested only through a heroic ritual, it is not done. If telemetry says "error" but not the state that produced the error, it is not done. If the handoff document cannot survive a tired engineer at midnight, it is not done.

That is the inside work. It is not a single dramatic breakthrough. It is making the system less dependent on memory, luck, and the one person who knows where the fragile assumption is hiding.

The market nobody explains cleanly

The Indian space story changed after the 2020 reforms. IN-SPACe made the private-sector path more legible, ISRO opened more interfaces, and the public conversation moved from "can private companies participate?" to "which parts of the value chain can they own?" That is a real shift.

The public markers matter. Skyroot's Vikram-S launch in November 2022 was the first Indian launch vehicle built by a private company to launch from Sriharikota, as ISRO records on its Mission Prarambh page. Agnikul's SOrTeD mission in May 2024 added another kind of marker: a launch from India's first private launchpad at SDSC-SHAR. IN-SPACe and public industry reporting also keep pointing at the larger target: a much bigger national space economy by 2033.

India is now committed to reach its vision of $44 billion space economy by 2033.

That sentence is the boardroom version of the opportunity. The engineering version is narrower and less cinematic. The ecosystem needs qualified electronics, manufacturable boards, better test access, ground tooling, telemetry stacks, mission software, documentation discipline, component supply, and teams that can move from lab artifact to repeatable subsystem without pretending physics got easier because the policy improved.

There is also a split between upstream and downstream space work. Downstream software can often move with normal software tempo: image products, analytics, mapping, communications services, climate intelligence. Upstream hardware cannot. It has launch calendars, vacuum, vibration, thermal constraints, RF, procurement, and the fact that a bad design can become expensive archaeology.

That split matters for young founders. It is tempting to look at the market and think the opportunity is in the most visible nouns: rocket, satellite, constellation, payload. Some of it is. But the substrate is just as important: electronics, power systems, test tooling, verification records, ground segment reliability, and boring components that work often enough for the heroic nouns to survive.

The hardware reality

Small-satellite electronics are a constraint fight before they are an innovation story.

Power is tight. Volume is tight. Thermal behavior is rude. RF wants quiet boards. The OBC wants predictable power and clean state. The EPS wants every downstream load to behave, which is adorable because downstream loads behave until the day they do not. The mechanical envelope turns connector placement into strategy. The test procedure turns vague confidence into measured evidence.

Bring-up is where a board stops being an opinion. The first power-on is not a celebration. It is a negotiation with reality. The current limit may save you. The fault may be obvious. The fault may be a footprint, a tolerance, a regulator transient, a clock assumption, a solder bridge, an ordering issue, or a line in the schematic that looks correct because your eyes have become bored of seeing it.

The useful habit is to make fewer private assumptions. Label things. Record measurements. Keep test notes. Capture why a component was chosen. Write down which state is allowed after a fault. Keep the handoff boring. Boring handoff is a gift to the next engineer.

This is where market language becomes irritating. A pitch deck can say "space-grade" in one word. The lab has to decide what that means. Which tests? Which range? Which failure mode? Which evidence? Which environment? Which reviewer? Which subsystem gets blamed first when a value is out of range?

If that sounds unromantic, good. Flight-facing electronics should make hype uncomfortable.

An honest word on credentials

Some credentials look impressive on a slide and still do very little work.

Award lists can be real and still be secondary. Filing records can be real and still be less load-bearing than the hardware around them. "Led a team of N" can be true and still tell you almost nothing unless the work produced artifacts that another engineer can inspect. A resume bullet can compress six months of hard work into one clean line and accidentally remove the only part that mattered.

I have become more careful with that over time. It is easy to over-index on the visible artifact because the visible artifact is easy for a reviewer to understand quickly. The harder truth is that deep-tech credibility comes from hours on real systems, subsystem ownership, integration scars, and evidence that survives contact with other people.

For the TSC period, the credit I trust is not a decorative credential. It is that I had to work across power, compute, RF, telemetry, ADCS-support electronics, validation, and production documentation before I was old enough to have the usual senior-engineer costume. I had to learn that hardware claims are only as serious as the test record behind them.

That distinction matters now because every founder story has a temptation to over-smooth itself. Mine does too. The better version is smaller and stronger: I got unusually early access to serious hardware work, I made the kind of mistakes young engineers make, and the work trained me to care about evidence, degraded states, and handoff more than appearances.

That is the credential I am willing to build on.

the computer's power resembled that of a bulldozer; it did not harness subtlety, though subtlety went into its design.

Kidder's sentence lands because hardware often looks blunt from the outside and exacting from the inside. A small satellite bus is not impressive because it looks delicate. It is impressive because subtlety has to fit inside power rails, connector choices, telemetry, thermal limits, and test notes.

What 23-year-old me got wrong

I overrated cleverness. I underrated paperwork.

That is the short version. At 23, I wanted the architecture to be elegant, the board dense, the logic sharp, and the system to have a clean idea behind it. I still like those things. But flight-facing electronics teach that the unglamorous layer is not bureaucracy. It is part of the system.

The checklist is not there because everyone lacks imagination. It is there because confidence is cheap and missing evidence is expensive. The test note is not there to slow the team down. It is there so the team can move without depending on one person's memory. The acceptance range is not pedantry. It is the difference between a result and a feeling.

I also got the software and hardware relationship wrong at first. I treated firmware as the part that made the board intelligent. That is true only in the shallow sense. The better view is that firmware is one participant in a physical negotiation. The board, power path, sensor behavior, timing, RF environment, and mechanical assembly all get a vote.

Once you accept that, your design taste changes. You stop asking only "does it work?" and start asking "what will it do when it is tired?" A brownout. A stale sensor. A missing packet. A clock drift. A delayed command. A test setup someone else has to repeat. The degraded cases are where the architecture shows its character.

That lesson followed me into robotics, Wabtec, and now JouleBridge.

The habit that stayed

The habit that stayed with me from the TSC years is simple: do not trust a system that cannot explain itself later. Did the bus enter a fault state? Did the EPS drop a load on purpose? Did the OBC record the transition? Could another engineer reconstruct the sequence without folklore? The domain has changed since I left nanosatellites. The discipline has not.

What this means for young Indian hardware founders

The best part of the Indian space moment is not that a few companies may become famous. It is that more young engineers can touch real hardware earlier.

That matters. A country does not become deep-tech serious through press releases. It becomes serious when students and early engineers can access boards, labs, mentors, test facilities, standards, procurement channels, and customers with physical constraints. It becomes serious when the path from college project to flight-facing subsystem stops feeling like folklore.

There is a trap here. The trap is to make everything inspirational and skip the hard parts. India does not need more young founders being told that passion defeats physics. It needs more young engineers being given problems where physics, manufacturing, regulation, documentation, and customers all show up at once.

The next generation should start with better defaults than my cohort had. More open reference designs. More honest failure writeups. More shared test facilities. More mentors who can say "this is not ready yet" without making it personal. More founders who understand that the fastest way to look serious in hardware is to stop pretending everything is already solved.

The practical checklist is not glamorous, but it travels. A founder who can show bring-up notes, power-margin records, RF assumptions, fault-state behavior, validation coverage, and handoff instructions is doing more than telling a better story. That founder is making the work easier for another engineer to inspect.

That is the version of ambition I can stand behind. Build something that can be checked. Publish enough of the method that another engineer can learn from it. Keep the claims smaller than the evidence. Repeat until the country's hardware ambition has more behind it than procurement luck and conference-stage optimism.

The boxes have to work. The evidence has to travel. Another engineer has to be able to pick up the record without needing the myth.

Sources

• CII press release on IN-SPACe and the 2033 space-economy target
• Business Standard interview with Pawan Goenka on India's space economy goal
• PIB note on IN-SPACe authorization for Vikram-S
• ISRO Mission Prarambh page
• Agnikul mission page for SOrTeD
• Aerospace America interview on the CubeSat boom
• Tracy Kidder, The Soul of a New Machine