[josephgruber]

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)?

[llcrabtree]

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.

[k1rcher]

> 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.

[llcrabtree]

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!

[alchemistmax]

Nice! Thanks for great ideas and questions.

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.