Full Stack Engineer, On-Prem Systems

About GalaxEye

• GalaxEye is a
• Space-Tech startup pioneering the world's first OptoSAR Earth Observation
• Satellite, integrating SAR (Synthetic Aperture Radar) and MSI (Multi-Spectral
• Imaging) on a single platform. As we move towards building a constellation of
• indigenous satellites, we are also developing advanced data platforms that fuse
• satellite data, AI analytics, and geospatial intelligence.
• The short version

You'll own features

• end to end — schema to screen. That means the data layer and APIs that turn
• multi-sensor satellite data into usable intelligence, and the interfaces analysts actually use to explore it: maps,
• imagery, dashboards, and workflows. And you'll build a lot of it to run fully air-gapped and offline, deployed inside
• defense and intelligence environments with no internet access.
• This is a full stack
• role. We care far more about how you think about data, failure, correctness,
• and the person on the other side of the screen than about which specific stack
• is on your résumé. If you're the kind of engineer who wants to know why something works — on both sides of the
• wire — and can pick up a new stack in weeks, you'll do well here.

What makes this different

• Most full stack jobs
• let you reach for a managed service when things get hard — a hosted database,
• cloud autoscaling, a CDN for your assets, Mapbox or Google Maps for your tiles,
• npm install at deploy time, Stack Overflow open in the next tab. Here you often can't. Systems run on isolated,
• on-prem hardware with no internet at runtime. That reshapes the whole stack:
• Dependencies — frontend and
• backend — are vendored and mirrored; builds are reproducible and
• offline-friendly. No CDN, no external fonts, no third-party script tags.
• Map tiles, basemaps, and
• imagery are served from local infrastructure, not a hosted provider. The
• UI has to render geospatial data with no internet behind it.
• The frontend is offline-first
• by necessity: it has to work fully within a closed network, degrade
• sensibly, and never assume a call to the outside world will succeed.
• Deployment and updates happen
• through controlled, secure processes — not push-to-cloud.
• Debugging happens with
• limited tooling and no live lifeline; you reason from logs, the network
• tab, and first principles.
• If that sounds like
• a fun constraint rather than an annoyance, you'll fit well here.

What you'll actually do

Build features end to end

• model the data, design the API, and build the interface — owning the whole
• vertical slice rather than throwing work over a wall.
• Design, build, and maintain
• clean, well-documented backend APIs — getting the contracts, error
• handling, and versioning right so the frontend (and other teams) can rely
• on them.
• Own the data layer: schema
• design, queries, indexing, migrations, and consistency, including spatial
• data and large raster/imagery datasets. Treat the database as something to
• be protected, not just written to.
• Build responsive, usable
• frontends for analysts and operators — including geospatial views:
• rendering maps, tile layers, and imagery, and making dense data explorable
• rather than overwhelming.
• Make it all work air-gapped
• and offline: bundle and vendor dependencies on both ends, serve tiles and
• assets locally, and design for a closed network where you can't reach out
• for help mid-run.
• Debug across the whole stack
• with limited observability — from a slow query to a broken render —
• forming a hypothesis, isolating the variable, and fixing it right rather
• than guessing.

What you'll learn here

Because this matters

as much as the work:

How to build full stack

• systems under real constraints — offline, on-prem, security-first — a
• skill very few engineers ever develop.
• Frontend geospatial
• engineering the hard way: rendering and serving maps and imagery with no
• hosted provider to lean on.
• Deep ownership of data
• integrity: migrations, backups, constraints, and consistency in
• environments where mistakes are expensive.

How to stay sharp without

• managed services — reading source code and docs, and self-hosting what
• others just call an API for.
• Full stack at the edge of a
• hard domain — satellite data platforms and geospatial intelligence —
• alongside [a strong engineering team / a lead who owns this].

Requirements

What we're looking for

Genuinely required

• 3-4 years of full stack engineering
• experience — you've shipped both backend services and user-facing
• interfaces to production.

Strong

• fundamentals on both ends. On the backend you understand why, not just which framework
• method to call — transactions, indexing, idempotency, connection pooling.
• On the frontend you understand how the browser actually works — rendering,
• state, the network layer — not just one framework's happy path.

Stack-agnostic

• ability — we're
• not hiring for one language or framework. Your competence comes from
• understanding, so you can be productive in whatever stack the problem
• calls for, on either side.
• A real sense
• for UX — you
• build interfaces for the person using them, not just to satisfy the
• ticket. You care whether dense, complex data is actually understandable on
• screen.
• Defensive,
• failure-aware thinking — you instinctively ask "what happens if this fails halfway,
• gets called twice, or the network drops?" and design accordingly,
• from the API down to how the UI handles an error state.

Systematic

• debugging. When
• something breaks — anywhere in the stack — you form a hypothesis,
• reproduce it, and narrow it down; you don't try random fixes. Critical
• when you can't google your way out live.

Self-sufficiency

and resourcefulness — you can figure things out from source code, docs, and first principles

rather than needing a live internet lifeline.

Dependency

• discipline —
• you're thoughtful about pulling in third-party libraries on both ends,
• knowing they may need to be vendored, audited, and left un-updated for
• long stretches offline. (Frontend dependency trees can get heavy fast —
• you keep that in check.)
• Ownership of
• data integrity —
• you treat the database as sacred, and care about migrations, backups, and
• consistency.
• Comfort with
• constraints and process — security discipline, careful data handling, and working within
• an air-gapped environment are part of the job, not obstacles to route
• around.

Bonus (nice to have)

Any of these are a

plus — we don't expect all or even most:

Experience with

• geospatial/mapping frontends (e.g. Leaflet, OpenLayers, MapLibre, deck.gl)
• and self-hosted tile serving.
• Experience with air-gapped,
• on-prem, embedded, or high-security deployments; reproducible builds;
• offline package mirroring.
• Depth in more than one
• language or framework, on either side of the stack.

Experience rendering or

• working with large raster/imagery or spatial datasets.
• Familiarity with
• containerization for isolated environments (Docker/K8s).

Experience with data

• migration, backup, and recovery in production.
• Comfort reading an unfamiliar
• library's source to understand it.