Wow. This is enormously impressive. I currently work for a small startup based out of Denmark in the renewable energies space (wind turbines) developing web based tools to assist in our ML operations.
With a lifelong obsession with cosmology and astronomy, and perhaps even more applicably relevant; our own human advancement to and into the stars, I have increasingly become more and more inclined to the notion of further developing my current skillset with the eventual goal of transitioning to the space industry.
My recent experience and exposure to renewable energies has given me massive insight to just how important companies like you guys are to furthering humanity’s progress. My question to you all regarding your technology, is how you manage what I imagine to be extraordinarily large, rich, and complex datasets that must vary between use cases (you mention hotels, debris removal, etc.). The data between these use cases must vary in structure— how is it normalized/standardized to work with your pipeline(s)? The commonality I see (as a fairly novice layman in terms of space technology) is of the rocket propulsion, orbiting, and payload delivery kind, but I’m sure the data it is far more nuanced and goes far beyond that.
Furthermore, is any sort of machine learning applied on your side, perhaps in some sort of statistical analysis / metric reporting?
I’m going to definitely keep an eye on you all at Epsilon3. Perhaps you will be looking for more engineers with web dev, data, ML, and cyber/info security experience in the future!
Huge props. I can tell there is an extraordinary amount of innovation involved with this venture. Excited to see where you all go with this =)
We have been very thoughtful to build as flexible a framework as possible to support all those various use cases you said (not only in our user interface but also our API). We want to give end-users across the continuum of use cases the tools they need to be able to make Epsilon3 as useful for them as possible.
We have a ton of ideas on applying ML on our side for exactly those use cases you described (metrics, analysis, reporting) but also for anomaly detection, error handling/risk reduction, and continuous improvement.
We have our job openings posted at https://angel.co/epsilon3/. We're always on the lookout for strong full-stack software engineers.
This is awesome and made my day knowing that the space industry is big enough to support a startup building this kind of ops tooling.
You said “you don’t hear about most of those on the news” and you’re right - most of the customer logos on your website I’d never heard of - is there a website / twitter / ? that you rely on for daily coverage?
I would love to build a better view of the industry, players, priorities.
Love this! It's certainly surprising that something like this doesn't exist for the space industry yet (and other industries that do complex texting and operations). Glad to see someone working to fill that gap especially as the commercial space industry starts to blossom. Couple of thoughts/questions:
1.) How do you convince space orgs that using a third-party SaaS offering is a better approach than building it in-house? Especially as part of the ERP the org may be using already?
2.) Does Epsilon3 support scripted procedures? What language(s) does it support?
3.) Any thoughts on a ChatOps like interface (e.g. Slack)?
Joseph, for #1, I've worked on in-house tools and:
1. They never get enough developers.
2. They usually get deprioritized in lieu of other projects.
3. Many small space companies don't have resources to build awesome in-house tools.
It can be really time consuming and take the team's focus off of the primary goal as well, so we try to get teams to focus on the things that they are uniquely qualified to do, rather than build software to support their operation.
> 1. They never get enough developers. 2. They usually get deprioritized in lieu of other projects.
As a dev currently building out several fairly-complex in-house tools for a small startup, I can relate to this first-hand.
It’s enormously frustrating as a perfectionist with a slightly neurotic obsession with (in a balanced and healthy way, trust me ;D) and appreciation for best practices, I have had to (against better judgement) sacrifice many things such as extensive time spent on in-depth automated testing, abstraction of reusable code for polymorphism and shared packages, extremely in depth documentation, and many other aspects that would contribute to long term viability and efficacy. This is of course for the sake of a business-friendly timeline, and that I can appreciate.
There is a definite balance, and I have (and continue to) learn enormously from this business view on software. The “it just works” ethos can be scary further down the road. The economic upsides to this perspective for an MVP or POC type of development are absolutely massive, but I can’t help but think this could be supplemented further by dedicating more resources to focusing on best practices.
Whether that focus comes from an internal team with more dedicated resources or a third party, I’m still unsure as to how that decision should be made.
Either way, it has been very helpful in further developing my skills in communicating things like tech debt (what notions like automated testing actually mean in terms of value to a SaaS company) to the CEO and other colleagues who do not have software dev experience.
This is 100% my experience too. Something has to give when you're developing a tool for in-house use only. The same practices you'd use for developing a tool for a larger audience can't apply because you don't have endless resources, personnel or time when developing in-house. Thanks for this information. It's super helpful!
1. Building in house is expensive, slow, and painful, and most teams have better things to spend their time on. We’re helping several teams move off their in-house solution because they aren’t satisfied with it.
2. We are building out automation and scripting capabilities. We support integration with Python scripts and other local commanding destinations via our API.
3. Love the idea! We already support real-time comments that are embedded in procedures. We want to build out even more things along those lines to streamline communications.
Is the any planned integration with requirement tracking software such as DOORS? If it were possible to flow test results back into the requirement specification systems it could seriously save a lot of time and money.
Also, for commenting on procedure steps are there any additional tools available for the text formatting? We find we have to do a lot of red lining and colour coding as things progress to track deviations in a simple way for customers and PA to find.
Most certainly! We are planning to integrate with all software packages that our customers are using to enable really efficient operations for them. We have a few Next Gen DOORS customers, as well as other requirements tracking tools. I love the suggestions!
In addition, we can comment and actively redline running procedures. If you want me to show you I'd be happy to. You can email me at email@example.com and in addition I'll make a small tutorial and link it here when complete.
Thats really cool to hear, I hate working with DOORS, so anything to automate the interaction is great!
If it is ok with you, can I pass on your information to our Business Development team, I will stay involved for sure, but they are the best positioned to see how the software could fit into our systems.
Congrats! Great to see YC supporting more software companies that are working towards finally bringing the "boring" parts of the sector into the 21st century.
If you're interested in exploring the idea of supply chain integration, I'd love to chat. We're an ESA-backed, online marketplace for the space sector , and we've built a few integrations already to bring tools and data together for engineers.
So excited to be part of Epsilon3 and helping so many awesome companies with their testing and operations.
I hope everyone saw the recent epic Blue Origin and Virgin Galactic flights. Those are just the first small step in what's to be a very exciting future. Epsilon3 wants to eventually help so many more people go to space. Now that we’ve had two billionaires go up to space, maybe someone in the HN community can be next?
Really excited to be part of this team! Laura was talking yesterday about tearing up at after the Blue Origin launch, not just because it's amazing to send people to space, but because it requires the work and communication of thousands of people to take them up and bring them home safe. We're excited to build tools to enable all of the hard work that leads up to a successful launch!
Thanks! No, the US Government can't access your data. Only you can. GovCloud is just a special portion of AWS that has extra security controls so that US companies are confident that all their data is housed in US servers and properly treated according to ITAR regulations. It's totally fine for companies outside the US to use and doesn't give the government any access.
We also support on-premises deployments if that's preferable to companies outside the US.
Yep, we are planning on hosting in other AWS regions as well. For pricing, let's discuss offline because it'll depend on a few things. Can you fill out the Contact form on our website (https://epsilon3.io/contact), and we can take it from there?
I don't understand yet the pain being adressed. If today it can be solved with pen and paper or Word, it looks to me that realtime sync or data visualization were not a must (disasters seem to be avoided today just as well). Nice to have, without doubt, but not a must. So your software makes it a nice experience for everybody involved, right?
Yes, it's been accomplished with paper in the past, but at great expense as many of the teams of the past were large. Take for example any control room of the 1960s, which had 40-60 people in it. Today's teams are scattered (and working from home much of the time), and much smaller (think less than 5) and must be able to accomplish the same tasks as those larger teams of the 1960s. Our software enables the teams to be smaller, more agile, and communicate better from anywhere in the world.
There's a ton of time wasted in miscommunications and lost paper records or illegible handwriting on test logs. And there have been many disasters and lives lost in the past, so anything that can be done to avoid that is worth seriously considering. Plus we make it a nicer experience and way faster.
Very true, papers are so time consuming and risky... eh. Otherwise maybe we are not thinking about the same events, so can you please detail some many disasters and lives lost? The only ones coming to mind are the space shuttles...
Excited to be using this product for ensuring clearly documented and easy to make test procedures for our propulsion testing, and eventually for our satellite operations. Keep up the good work Epsilon3 and I look forward to becoming a hardcore power user!
Lol, thanks Pat. I keep telling the team that we won't allow acronyms. That feature is 100% on the list. Currently they are allowed, however future revisions might not allow acronyms, or might force you to define them. Certainly keep your eyes peeled for this new *feature*.
We are planning to have some dedicated functionality to help with non-conformance, anomalies, and other related things. We also plan to integrate with JIRA for separate reasons too.
We have not implemented a standard data scheme yet, but that's a great idea. We've been letting our customers set up their own schema and structure based on their needs, but I can definitely see the value of being able to adopt an industry-standard schema, so that's a great idea.
I'd love to learn more about your use case and understand better where you're coming from on those points.
Interesting. This sounds like a good fit for CRDTs somewhat, though a centralized architecture might offer more robustness guarantees. On the other hand, it would be quite easy to display sync status as part of the UI.