The longer vision behind Bhaskar
The more I worked with satellite data, the more I noticed that the difficult part often began after the data had already been collected.
A satellite could observe the right place at the right time. The imagery could exist. The scientific method could be well understood. Yet turning that observation into something another person could reliably use still required finding the right source, preparing it, combining it with other information and fitting it into a workflow that was often built from scratch.
That gap is what led me to Bhaskar.
The observation may already exist. The system that carries it into a real decision often does not.
Space has become better at recording the world.
The systems that help people interpret those observations have not developed at the same pace.
This does not mean satellite data is unused. Every satellite is launched for a purpose, and many organizations already do sophisticated work with it. The problem is that much of this capability remains fragmented across providers, internal systems, specialist teams and individual projects.
Different missions produce data through different formats, cadences and processing systems. Customers then have to connect those sources to their own context, historical records and operational processes. Much of that work is repeated, but relatively little of it becomes shared infrastructure.
The result is an industry with increasingly capable sensors, but a downstream layer that is still expensive to assemble and difficult to maintain.
I believe there is room for a company that works in the layer after collection.
Not another satellite operator, and not simply another visualization tool.
A company that builds the systems through which different forms of space data can move reliably, become part of repeatable workflows and eventually support better decisions.
The opportunity is not based on the claim that no one uses satellite data well today. It comes from noticing how often capable teams still rebuild the same underlying work for each provider, customer and use case.
Bhaskar is my attempt to understand whether that recurring work can become durable infrastructure.
Build reliability first, then compound above it.
I do not think intelligence can be added meaningfully on top of unreliable data movement. The company therefore has to develop from the bottom up. Each layer should make the next one possible.
Infrastructure
Reliable products begin with reliable data movement.
The first responsibility is to make data move consistently through a system. That includes ingestion, normalization, cataloging, orchestration and delivery across different sources.
If every new dataset creates a fresh engineering problem, the products built above it will remain fragile. Infrastructure should reduce the amount of work that has to be repeated before a customer can begin using the data.
Workflow products
Infrastructure matters when it improves real work.
Customers rarely need raw processing for its own sake. They need a recurring task to become faster, clearer or less expensive.
The second layer turns technical capabilities into repeatable workflows for monitoring, interpretation, analysis and delivery. The product should fit the decision a customer is already trying to make rather than expecting the customer to reorganize around the technology.
Intelligence
Intelligence should come after reliability, not instead of it.
Retrieval, alerting, summarization and decision support can reduce interpretation costs, but only when the data and workflows beneath them are dependable.
AI cannot compensate for missing provenance, inconsistent preprocessing or a poorly understood customer decision. The intelligence layer should improve a trusted workflow, not disguise the absence of one.
Infrastructure
Reliable products begin with reliable data movement.
The first responsibility is to make data move consistently through a system. That includes ingestion, normalization, cataloging, orchestration and delivery across different sources.
If every new dataset creates a fresh engineering problem, the products built above it will remain fragile. Infrastructure should reduce the amount of work that has to be repeated before a customer can begin using the data.
The platform should be earned through products.
I do not think Bhaskar should begin by trying to build a horizontal platform for the entire space-data economy.
The practical starting point is one narrow workflow where relevant data already exists, the integration cost is visible and improving the process changes a meaningful decision. Building that workflow well should reveal which parts are specific to the customer and which parts deserve to become reusable infrastructure.
The next product should not begin from zero. It should inherit the pipelines, data structures and methods that proved useful in the first one.
Over time, a broader platform can emerge beneath a series of carefully chosen products. The platform is not the starting claim. It is what compounds when the company repeatedly solves the right problems.
A thesis is useful only if it can survive contact with the market.
Bhaskar is still early. The immediate work is not to defend this thesis as though it has already been proven. It is to test it.
I want to understand which integration problems genuinely recur across organizations, where existing systems create the greatest operational friction and whether customers value a dependable workflow enough to change how they currently work.
I also want to learn how much infrastructure can be reused across markets without flattening the differences between them.
The questions guiding the current commercial research are:
- 01Which parts of the space-data workflow are repeatedly rebuilt?
- 02Where does fragmentation create a measurable cost in time, engineering effort or decision quality?
- 03Which customer workflow is narrow enough to solve well but important enough to build a company around?
- 04What should remain specific to a market, and what can become shared infrastructure?
- 05Where can intelligence improve a trusted process rather than add another layer of noise?
The answers to these questions will determine what Bhaskar builds first.
Software around space data will become infrastructure too.
Space infrastructure is usually understood as the hardware that reaches orbit: launch systems, spacecraft, sensors and communications networks.
I believe the software through which space data moves will increasingly become infrastructure in its own right. The pipelines that organize observations, the workflows that bring them into real operations and the intelligence systems that help people act on them can become an enduring layer of the space economy.
Bhaskar may begin with one narrow workflow. The longer ambition is to help build the infrastructure through which many forms of space data move from observation into use.
That is the company I want Bhaskar to grow into.
Why Bhaskar
Bhaskar is named after Bhāskarāchārya II and a longer Indian tradition of careful astronomical observation. Bhāskara means light-maker and, in Indic traditions, is also a name for the Sun.
The Sun is often imagined as all-seeing, not because it knows everything, but because its light makes everything visible. That is the idea behind Bhaskar: a decision-intelligence system that can see across fragmented sources, reveal the connections between them and help people act with greater clarity.
Siddhesh Badani
Founder, Bhaskar Space Intelligence Studio
Continue the conversation
Bhaskar is still taking shape through commercial research, technical exploration and conversations with people working close to these problems.
Explore the markets