Behind the Scenes: How Dauntless XR Landed a NASA Contract
Ever wondered how a small tech startup with zero government contracting experience lands a deal with NASA?
In this episode of the Becoming Dauntless Podcast, we pull back the curtain on how our four-person team at Dauntless XR secured a NASA contract—without any prior performance history. If you’re a founder, product leader, or technologist curious about breaking into aerospace or government work, you’ll find actionable insights, lessons learned, and honest reflections in our journey. Listen to the full episode below and read on for key highlights, practical takeaways, and answers to the most common questions we get from other startups about winning NASA contracts as a startup.
Episode Highlights:
Why NASA?
Our motivation and how we navigated the intimidating world of government contracts as a small, new business.The SBIR Program & NASA’s Unique Process:
How we discovered and approached the NASA SBIR (Small Business Innovation Research) program—and why most startups overlook the best opportunities.Choosing the Right Topic:
The importance of aligning your core tech capabilities with NASA’s mission needs (even if you think you’re not a “space” company).Building a Winning Proposal:
Key differences between NASA and DoD proposals, and how we tailored our pitch for academic rigor and peer-reviewed credibility.The Power of Networking (and Internal Champions):
Why building relationships with NASA centers and subject matter experts can make or break your bid—even if you have no prior connections.Lessons from the Agile Retrospective:
How running a “retro” helped us identify what worked, what didn’t, and what we’ll do differently next time.Start, Stop, Continue:
Start: Early data exploration, creating internal marketing materials, and annual topic reviews.
Stop: Overanalyzing data, assuming your tech isn’t a fit, and chasing low-probability programs like NASA Ignite.
Continue: Delivering MVPs, releasing free public apps, and documenting everything.
Try It Yourself: Aura Space Weather Data Explorer
We turned our NASA contract work into a free, immersive app for Meta Quest.
👉 Download Aura Space Weather Data Explorer
Frequently Asked Questions
Can a startup with no government experience really win a NASA contract?
Yes! Our team at Dauntless XR had zero prior performance with NASA or other agencies. With a focused proposal, a willingness to learn, and by leveraging the SBIR program, we secured a contract in less than two years.
What is the NASA SBIR program and how do I apply?
The Small Business Innovation Research (SBIR) program is an annual opportunity for small businesses to propose R&D projects that align with NASA’s needs. Topics are released each December, with proposals due in February. There is a second program, NASA Ignite, which is similar but focuses more on technology with commercial applications that is open each summer. Start by reviewing topics as they are released, building relevant relationships, and crafting a proposal that addresses NASA’s mission.
Do I need to know someone inside NASA to win?
Our win came from a strong proposal, not existing relationships. Proactive networking during the year can help for future efforts, but the evaluation process is designed to award based on merit according to the priority topics.
How important is it to tailor your proposal for NASA vs. other agencies?
Extremely. NASA’s process is more academic and research-focused than agencies like the DoD. Peer-reviewed citations, clear articulation of the mission fit, and public outreach elements are key.
What are the biggest mistakes to avoid?
Don’t get lost in NASA’s open data portal—pick your data sources early. Avoid chasing programs with sub-1% win rates (like NASA Ignite) unless you have a perfect fit. And don’t assume your technology isn’t relevant; dig for the root problem NASA is trying to solve.
How can I maximize my NASA contract for business growth?
Release a free public app or MVP based on your NASA work to support outreach and internal marketing. Document everything, manage your project with agile methods, and look for ways to repurpose your learnings for commercial offerings.
Transcript
Lori-Lee: We won a NASA contract as a team of four with no past performance after just two years of being in business. It wasn't luck and it wasn't as hard as people think. We even replicated the process and have taught others to do the same. Welcome to Dauntless. Today we're joined by our CTO James James, welcome to the Dauntless Podcast.
James: Thanks for having me.
Lori-Lee: We appreciate you taking the time to give us your perspective today. Just to give a bit of backstory, we'd been full-time on the business about a year and a half, and then we decided that we wanted to work for nasa. I'm thinking of that like a legally blonde scene where she's just like, did she wake up one day and decide she wants to go to Harvard? It was sort of like that. And we had been looking at small business contracts through the SBIR program for Air Force and nasa, but we hadn't gone after anything outside of DOD and we decided that we wanted to change that. When most people look at, Hey, I'm a small business and I want to go work for nasa, in whatever capacity, most people will go after SEWPs or SEWP which stand for. Solution for enterprise wide procurement. But everyone just says SEWPs and there's a whole bunch of them.
They have different kind of categorizations and different things that they're procuring for, and there's a ton of companies that you will find listed under a SEWP In my opinion, if you are kind of new to government contracting or you've never worked with NASA before, it is a bit of a waste of time to go after a SEWP unless you. Are connected with a company that's already in one and they wanna subcontract you, but we can talk about that a little bit more later. Getting back to our backstory. We decided, okay, we want to bid on something outside of DOD and NASA was a logical first step for us.
The problem is NASA's topics. The topics that are just for small businesses doing r and d, only open one time per year and it opens in January and they close in February. So if you miss the window, you're done for the year. In previous years, we had always missed the topic openings.
So we just had to, you know, wait, but this time, the end of 2021 for whatever reason. We've remembered, I jumped onto their website and had a look through all of the topics and, you know, there was a lot, it's a lot to go through and it's not organized the same way as it is for DOD or the other agencies, but I went through all of them.
And highlighted a few that could be relevant to the technology that we were building with extended reality and building on some of the work that we'd done for the Air Force. I don't know if you two remember this, but I like white boarded out an entire plan, and like presented it at a meeting.
Sofia: You were so excited and for some reason, so worried that James and I would say no, that you were like, I came with ideas and objections and answers to your objections about why we should.
James: Yeah, and the prospect, quite frankly, of talking in NASA was just, you know, so exciting. How could we not, you know.
Sofia: Yeah.
Lori-Lee: I was fully prepared to be like, this is why we should go after this. Here are all of the benefits. And then I remember after you all were just like, yeah, that seems like a cool idea. Let's do that. I wonder if I still have a picture of my whiteboard. It took me like an entire morning to put that together, but it was worth it, I think just because of how different NASA topics are compared to DOD, it's a lot more academic. It definitely needed that kind of breakdown. But yeah, so that was in January of 2022. We selected the topic we wanted to bid on, which was, I don't know the exact topic number, but it was for space weather and space weather monitoring and prediction. We broke down the topic, and we put together a proposal about how our technology would fit into this kind of NASA mission for monitoring. Activity coming off of the sun and how that would affect humans on earth, humans and assets in space, all that good stuff. We put together a proposal, which as I alluded to before, this one was a lot more academic than our normal Air Force proposals.
There were a lot of peer reviewed citations. We referenced current events in the New York Times. It looked very different. And I think that was definitely key to winning it. If we had just tried to copy paste over something from the Air Force, it probably wouldn't have gone over as well.
And yeah, then we submitted in February, it went off into the ether and we didn't get the results till June. And you'll find if you go through this same process NASA does not notify you ahead of time that you've won. They post the results publicly and anyone, anyone can see what companies were awarded.
Obviously, they don't if you don't get anything. Only the winners are there. And I actually didn't know that we'd won anything until I started getting all these emails from different vendors that support or spam advantage of SBA companies because my information was all publicly listed with the award. I was like, oh, I guess we won something and went on and, and checked and there you go. We'd won our first contract. That's kind of the backstory. And today we're gonna jump on here and do a retro or retrospective. And I was wondering, Sofia, if you could tell us how that works and why we do it, why other people should consider doing one and all that good stuff.
Sofia: Yeah, so we executed the contract, right? And we're gonna drop a case study on what we learned, and what we did separately. Today is a chance to listen in on a team, retroing, how it went, right? So the concept of an agile retrospective, I can break it down a little bit. It's a dedicated time, traditionally at the end of a sprint. But it can be done at the end of a project as well where you reflect on what worked, what didn't, and what we can improve moving forward. It's really founded in the principle of continuous improvement. And it's just an opportunity to take a pause and take a step back, and look at communication, execution processes, anything that we should learn and adapt from as we move forward in different projects.
So there's lots of different formats that you can use for retro. Today's retro, we are going to use the start, stop, continue format, which is one of my favorites. But maybe in future videos we'll experiment with other formats to introduce you guys to different retro formats. If you wanna mix yours up, start where I'm asking you guys for new ideas.
Practices or approaches that we think could make a positive impact that we didn't necessarily do, that we think we should do on a next project stop would be things that we feel like added unnecessary friction. To the project or to our processes continuing would be things that worked well and should remain part of our process moving forward. I like this format. I think it's really simple and I think it's really actionable. Keeps things really clear. Gives you great takeaways for what you do next. So I am gonna act as our scribe. So I will be sharing my screen and can't wait to hear what we think about.
We are going to start with the start, right? We like to sandwich it, start, put, stop in the middle. Continue things we did well pat ourselves in the vacuums we could keep doing at the end. It's a nice structure. The sandwich works y'all. Okay. Lori-Leelee, do you want to go first?
What is something that you think we should start doing that we didn't do during this contract.
Lori-Lee: Yeah, I can start us off and just to, add on to explaining a, a retro, if you come from a non-tech company background or you don't use agile, these are sometimes called the lessons learned or like a lessons learned review.
Sofia: Project Post Mortem is the other one I've heard in more corporate
Lori-Lee: Yeah, corporate postmortem, lessons learned. It's all the same intent. Just slightly different names, but yes.
Things that I think we have started doing and that I'd recommend start doing is reviewing the NASA topics yearly. They drop in December. You have a month of pre-release and then a month to. Submit a proposal. So there is actually quite a bit of time to go through everything and see if there's something in there that's relevant. and then the other thing I would do in the time that you're not looking at proposals is building a network with the people at the different space centers. So I'm in Houston, we have Johnson Space Center here. And they hold a lot of events that are open to the public that you can go to learn. More about working with NASA and the different programs that they support at each of the centers. NASA has an Office of Small Business, and I believe each space center has their own, and they do their own events.
They have their own resources and outreach and everything. So just, doing more of that during the year so that when the topics are released, some people advocating for you on the other side.
Sofia: Yeah. It's good that you brought that up because I think something that we learned about NASA specifically that's a little bit different than DOD is the way that their selection process works. There's some initial down-select, but then if there is someone inside of NASA that wants to champion your proposal, they actually go in front of a panel and they're like, I think we should fund this one, and here is why. So. Obviously we won without having a huge network. So you can get through without it, but having more people, having already been familiar with your business and the problems you're trying to solve and not just going off of what's in the single proposal, is helpful. So, yeah, that's a good one.
What about you, James?
James: Yeah, I think that's especially helpful on the development side in terms of getting in contact with subject matter experts who can help explain use cases. And how exactly that data is being used in a day-to-day context. You know, I think that we, I'll get into this later, but I think that we spent a lot of time trying to understand the data as opposed to just trying to figure out what exactly they needed to have displayed and what they focus on and their workflows.
And so yeah, like there's a little bit of explanation that has to happen regardless, especially when it comes to space weather in terms of like, when is the data coming in and where are these sensors located? What are the satellites that are feeding that data to the different endpoints? But yeah, especially building that contact list of people who are able to answer these questions for you.
You know, nasa, they have a really big mission on a paper thin budget. I understand why it was difficult trying to get in contact with people to get explanations on these things, but it's not a consistent thing that you're able to rely on to get these answers.
Lori-Lee: Yeah, that's kind of that. That's something that we saw with DOD as well, where with these solicitations, they're telling you what they think they need. They're not telling you what the problem is that they need solved. And I understand why things operate that way, but then as a technology company coming in and trying to, you know, match these things up, it doesn't necessarily work.
So yeah, if you can get to the point where you have enough network that you can talk to someone and they can tell you. Not what they think they need, but the problem they are trying to solve that is hugely valuable. You will put together a much better proposal if you have that information, but it's not a given.
You have to go work for it.
Sofia: Yeah, good point.
James: That's why I particularly enjoy your approach, Sofia, where you just get them to start talking about the problems that they encounter. You know, 'cause from an engineering perspective, I just want them to like, just answer the question, like, what do you need from me? As opposed to trying to understand what their actual use case is, it's a much better approach and highly successful.
Sofia: Yeah, you gotta tap into everyone's enjoyment of complaining about their job, like. Universal truth. Everyone likes to complain about their job a little bit. Obviously not us, but it's yeah, if you can get people to complain about their job, about what's annoying about their job, like you can really learn a lot about what their requirements actually are in a way where they're not like sitting down and being like, well, I need this solution to do X, Y, Z. Before I get into my starts James or Lori-Lee, did you have any other ones?
Lori-Lee: No, I'm good.
James: Yeah, I have one other that's related to the data that's coming in. Something that we encountered on the engineering side that I think would be very beneficial to remove friction early in the process is to start getting into the data early, start trying to understand the schema and start trying to understand what the shape of the data is that's coming in.
Because what we encountered a lot as we started diving into this project is that, the different sensors and the different information data payloads that are coming in from them are, you know, quite frequently. Proprietary data objects and their own formats, and each one will be different depending on which satellite it's coming in on, even if they're on the same network.
I think the one that comes to mind is the way that the GOES network, would send data and it would really depend on which GOES satellite you were getting the data from, you might get an older data format because it was one that was sent up early in the project or another one that was sent up later.
And so now they changed to a different proprietary data object format and a different schema. And so you had to account for that even though they were trying to depict the same thing. So getting into the data early, trying to understand the shape of it and trying to understand what data sources were available to you.
Lori-Lee: So with the NASA products, like with their data products, James, are most of them publicly available?
James: Oh, absolutely, absolutely. So NASA's open data portal is an incredible resource, but that's something that's interesting, that I would put in the start and the stop category at the same time. So starting to get into the open data portal early. And figure out what data you have available. Absolutely critical of success.
Spending too much time getting lost in there, trying to dig through their huge, huge library of available data. It’s something that you can really get lost in. It becomes a time sink, and so at a certain point, you just have to kind of rip it out of your own hands and tell yourself like, okay, this is the data source that we're going with.
And we're sticking with that. It's really easy to get lost in just the pure volume of data that's at your fingertips and it's not organized particularly well. And so that's really the issue that you have to overcome early in the process. It's trying to figure out how to work around their organizational choices that they made.
I'm not gonna say right or wrong, but just the choices that they made in terms of how they're organizing that data that's available. But yeah, stopping yourself at a certain point and just committing to one is critical.
Sofia: Yeah, that makes sense. And agreed. I think we didn't actually get into the data until after kickoff. And in retrospect, we probably, as soon as we got the award notice, would've started the initial data exploration. And that probably would've made the rest of the feasibility study a lot more. Smooth sailing. So that's a good one. My start is one that is a departure from our other projects, which is why I think we didn't do it, but it is creating short form materials that can be distributed within NASA about what you're doing sooner. Previously on these types of contracts, we weren't creating that type of material really early on.
And what I'm talking about is I'm talking about short videos, explaining what you're doing, like, you know, 60 seconds or less and one pagers explaining, what the problem is you're trying to solve, what technology you're trying to use to solve it, and like what's the kind of scope of the feasibility study or what result are you expecting? Generally speaking, we would early on in a contract like roadmap planning type documents. And for us, I felt like we started getting traction on getting connected to more people in NASA once we had some like videos that our contract contact could send to people. So I regret, I think we were a good, you know, 60 days in before we started sending content that then he very quickly started distributing and then we were getting more teams reaching out to us and I wish we had just. Though we didn't necessarily have video, maybe we'd spun a one pager out of being like, here's, if you take our 40 page proposal and distill it to one page, this is what we're trying to do. that you think might be interested in this, can you blast this off to them? Right. So that was a lesson learned for me was creating short form marketing materials for internal use within NASA at the beginning of the contract.
Lori-Lee: The marketing. on this one was way higher than what we were used to or what we were expecting. I think our technical point of contact had to like sit us down and explain that there's a lot more internal selling that you have to do to move things forward. Had we known that earlier, we would have started it earlier. Like Sofia said, that was completely different to how things run in DOD. Like you are not necessarily running around shouting from the rooftops about what you're building.
Sofia: Yeah, no,
Lori-Lee: Yeah.
Sofia: I mean honestly I think we've carried that forward in multiple projects since then, but that was definitely something that came out of this specific one. So. Alright. What should we stop doing? James kicked us off with, don't get lost in data exploration at some point. Pick your data feed and go. Do you have other ones, James?
James: Yeah. On that note you know, I kind of mentioned this earlier, but stop trying to spend too much time understanding the data. What the data is trying to depict, necessarily, you know, like I'm not an astrophysicist. I don't claim to be, you know, the folks at NASA are incredibly smart people, and sometimes I'm sure the two of you can agree to this feeling of when you're speaking to them and they're trying to explain what it is that they need for this data, you're very quickly realizing that you're in over your head and you're talking to people who have just like.
Decades of knowledge behind them and you know, to, in their eyes, they are dumbing it down for you. But, you know, the reality of the situation is just, you know, I have a high school understanding of physics, and it's just like, that's about as far as it goes. And so trying to understand exactly what the data is depicting is not as important as what it is that they need to see.
And what is it that's gonna make their life easier? And so a big part of this, I think that came up in the space weather contract with them. When we were looking at graphics and depictions of the data that they're using today, it didn't make a whole lot of sense to us, but it made perfect sense to them.
And so just trying to lean into that and understand ways that we can improve, The visualization of the data from their perspective as opposed to ours, you know, in a civilian mindset. And so, I think a lot of that is also leftover things that we were experiencing with DOD where we're trying to make things, you know, quote unquote marine proof, so to speak, or, you know, not to call anyone out specifically, I guess.
But yeah, I think that a big part of it was, you know, we stopped trying at a certain point in engineering. Or the development to understand or try to depict things that made sense to us and started trying to depict things that made sense to them. And then we were able to really focus on the important aspects of what they needed out of the usability.
Lori-Lee: There was a bit of a push and pull as well on that front because part of the requirement for the contract was to produce something that enhances public understanding of space weather, so something that is going to make sense to the average person off the street. Is gonna be a vastly different experience to someone who has a PhD in Heliophysics.
Right? And we had to figure out, like, what is that balance? Who do you prioritize, you know, in that experience And TBD if we got it right, but I like what we built.
James: Yeah, I think, you know, at the end of the day, I think that we ended up striking a pretty good balance between the two. And I think that what really was critical for success in that factor was, you know, when we were displaying, I. Data visualizations. We made a divide between the graphs and bar charts and things like that that were being pulled from raw instrument data and being displayed, which is typically more of a science focus anyway.
And so we started leaning into depicting things in that nature in the way that scientists would expect them to be. And in ways that made sense to them, whereas the visualizations for the public were a little bit more eye catching or representative of what the data was trying to show. So in terms of like the charged energy particles that were coming off the sun, for example, we worked with a lot of visualizations.
I'm sure you two remember, you know, trying to show the trajectory of those particles coming from the sun and being detected by a satellite. And how that was interacting with the earth. And so that was, I think, the balance that we managed to strike and it, I feel like that was fairly successful in the way that we divided those two realms.
Lori-Lee: Yeah, we went through that, it's its own topic that would be interesting to go over, but how we decided to visualize the different particles coming off the sun, because we started off being like, well, this is what.
Sofia: Well, this is what.
Lori-Lee: We think it is actually happening, like what it looks like, but then this is what the sensors are detecting and we don't actually have a picture of it.
We just have what the sensors are detecting. So there was a departure from like, well this is representative of what we think it looks like, is representative of when the sensors are going off, basically.
Sofia: Yeah,
Lori-Lee: It was a whole journey. It doesn't sound like much to recap it, but yeah.
Sofia: I'm gonna put it in a continue as a splitting end user needs from a. Design perspective, because there are use cases in other parts of our projects where I can see that we really need to, you have two related end users using the technology in slightly different ways than you do really need to separate their design requirements, right?
Because again, what a physicist or astrophysicist is looking for versus what you or I are looking for when we're trying to be like, what the Aurora forecast is different. But I like that. One of my stops is actually a stop to winning me so slightly outta the bounds here, but I, I do think other startup founders or people who have worked with one agency might have this.
I think it's worth saying, assuming that your solution isn't a fit for certain agencies. In my head, we were an XR company, which had nothing to do with space exploration. I was just like, oh, NASA does space exploration not relevant. And really, I think this is like a shout out to you, Lori-Lee Lee, because you did a good job looking at what NASA was asking for and then lining up the root issue with a core capability.
Right? So the root issue was. Space weather has many disparate data sources, and you're talking about a 3D impact in space that you're trying to interpret and forecast off of a 2D screen. And then you look at our capabilities, which we have with Aura, which is complex 3D data visualization. There was so much marriage between that.
So I think for me it's just to stop writing off a particular agency is not relevant to us. And really break down what a root issue might need for an end user and what the core capabilities we have and see if something lines up. What about you, Lori-Lee?
Lori-Lee: My stops. Okay. I'll try not to get too much on my soapbox here, but, I think we, we immediately need to stop applying to NASA Ignite. I will not be putting us through that again. For context. NASA Ignite is different.
Sofia: Different than this one
Lori-Lee: It is different to this contract. It's a different program. It's related, it is a different award, different application process.
But what it is, it's sort of NASA's answer to a direct to phase two, which is a contract where you can skip the feasibility study stage and just go straight into developing a prototype and they spun it up with the intent of. Giving companies an opportunity to very quickly, relative to government timelines, take commercial technology and make it fit for NASA use.
So I think it's like $850,000 and you get like, 15 months to, take something that you already have and make it applicable to solve one of NASA's problems. On the surface, that sounds great. I mean, we already have commercializable technology, so this should be a pretty good fit, they only award like five contracts per year. Under Ignite,
Sofia: Which we didn't know when we were applying.
Lori-Lee: didn't know. So that's like less than a 1% chance of winning and to you know, level set. The other agencies for your chances of winning are like 20%, sometimes higher. it's very uncommon to be in this sub 1% chance of winning. Kind of levels. So yeah, for the amount of work you have to put into it, like, no, we'll not be doing that again.
And then also the topics that they had, we were like, oh yeah, our technology can be applied to this particular topic, what they didn't say. that they were looking for very specific technology types to solve these problems. And we were looking at this, I think, was it 2023? Must been 2024, but what they ended up awarding was like a hundred percent to AI companies. Which is fine, but it didn't say anything in the solicitation that they were looking for AI companies to solve these problems. So we come in with an xr, spatial computing technology. They are immediately probably gonna put that in the trash 'cause it's not what they were looking for. But we didn't know that.
Sofia: Yeah, we wouldn't have bid.
Lori-Lee: no, we wouldn't have bid we, it's not like we were doing it on principle or out of pride. We just thought it was a good match. So yeah, going forward. We're gonna stop, probably doing the NASA Ignite. Proposals stick to the standard ones. And, this is gonna sound odd, I would stop trying to sell technology to nasa. NASA's a great collaborator for doing research and development. They have, you know, like as James pointed out, they have lots of data. They have problems that need solving that are difficult to solve. partner. But they buy in such low volumes because you know, there's only one international space station, there's only one lunar mission. Even if you're selling, you know, like if we're selling a headset or we're selling software applications, they're only gonna buy max five licenses, which is fine. Like they don't need more, but that's your game plan is to sell technology to nasa, that's, that's not a great revenue stream.
I think if you want to have NASA as one of your revenue streams, you are better off providing them services, not products. And in this case, the research and development is a service. I think we've seen some other companies that are providing like. operations services to nasa. They're not even, you know, they're not selling them technology.
They're literally selling them services and that's like a hundred million dollars contract. That's way more than selling them spacesuits. So, I know it sounds a bit odd, but like stop drives, sell technology to nasa.
James: Yeah. You know, and you kind of touched on this earlier, but you know, I think what was the turning point for the interest that we got out of this project was the fact that we stopped trying to sell it as a new technology that they could benefit from, but instead as a public outreach tool.
Because they were very interested in making their data available to the public and getting people to understand the general public, to understand what it is that they were trying to depict and why this is important to them. And just increase the amount of interest in traffic that was involved with space weather in general.
And so, yeah, I think that was part of. Like what I was talking about before, it was less about, you know, something that we weren't developing something that, you know, the scientists necessarily were going to use on the day to day. It was more about taking what they already knew and making it a more digestible form for the public.
Sofia: Yeah, so that segues us to continue because my continue is release a free app. So we've now done this off of a couple of our projects, but NASA was the first time that we spun out a portion of what we built for them and made it available for free. It's called Aura Space Weather Data Explorer. If you have a meta quest, you can access it and it doesn't have all of the kind of physics renderings of what the effects of a corona mass ejection or a solar flare would be. But it does show you that all of the readings that are coming from those satellites live in an immersive environment where you can see where those satellites are relative to the sun and what those satellites are gathering. So I would say that is because I think it. Really aligned closely to their goal. I wish we had released the free app during the period of performance rather than after the period of performance. I think it actually would've helped us for that internal marketing better. But I still think the continue is, if you can spin any work that you do with NASA out into something that just is a public use, it's very aligned to their mission.
And at least for us was good for marketing. And it's interestingly still, a growing app. We still have more monthly active users, month over next, even though we're not making significant updates to the app at this time.
James: Yeah. And I think that one of the reasons, well, one of the things that, you've mentioned here before already was one of the reasons why we were able to pivot to a free public app so quickly is because we did refocus our efforts into the user experience and the design aspect of it, as opposed to trying to wrap our heads around the, all the data that was being fed into it.
And so when you put the extra time and effort into that last little bit, that last little, like 10% of effort. That goes into really making sure that the, the experience and the usability is polished and nice and easy to interact with, especially when you're talking about xr where there are not a whole lot of conventions that are set in stone yet, and it's a fairly new technology that people have to interface with, making sure that they don't wrestle with the technology in and of itself.
And so I would say that that was one of the reasons why we were able to be so successful in that regard.
Sofia: Yeah, that's a good point. Another continue I have that, kind of random, we opted for the sake of this project, even though it was a feasibility study. So from an R and D perspective, there was a lot of R. There was development, like, yes, it resulted in an app, but there was, there was a lot of research first just on what the data schemers were, what was feasible, what was possible were those data streams, XR ready. But one of the things that I think helped us as a team, just like, stay efficient throughout the period of performance was managing the work in a backlog with scrum ceremonies. So even though they weren't necessarily stories that resulted in features, they were a lot of just. Assess this data feed, assess that data feed and rate it on whether or not it's ingestible, non ingestible, useful, not useful, whether it aligns to the kind of the gold standard, yes or no. I think the fact that we manage all of those tasks as stories with acceptance criteria and in a backlog and through the scrum ceremonies like standup and, the, the other things helped us. Make sure that we were moving through them and that we got to the development in time, right? Like, yes, that app didn't go live in the period of performance, but it was ready shortly after and the demo was ready during the period of performance.
And I think that was really only possible because we managed the research work, the same way that we managed our development work. And I think it worked really well for us as a team. There was like zero friction in trying to fit that work in alongside our other work.
James: Yeah, I couldn't agree more. And actually that kind of segues into one of the points that I was going to put in continue was maintain your internal documentation about like. Endpoints and what data is available to use inside of your application. A lot of times, especially going through the open data portal, you'll see that there are a lot of different endpoints, even if they're all dealing with the same type of data.
I'm sure the two of you are just sick of how many times we said that while we were developing it. But there are so many different disparate endpoints and every single one requires its own interface methods, its own class structures and things like that. You don't even know if they're necessarily gonna have the same file system structure on the other side when you're actually trying to access the data.
Every single one is more different than the last. And so the only way that we were able on the development side to maintain any sense of order and actually deliver something was that we were religious about how we maintained our internal documentation with what data is available completely separate from developer documentation.
Lori-Lee: What did you use to do that?
Sofia: Yep. Great.
James: It honestly, we just used the same documentation tools that we use now. It was a lot of markdown files that were stored in a GitHub repo. A lot of Google talks or, you know, just a, a shared resource. Yeah, exactly. And so we came up with our own structure in terms of naming the resource itself and the, we would go with a convention that was the name of the resource itself, the realm that the data had to deal with, specifically what kind of data delivered inside of that realm and the relevant endpoint to reach that one.
And so with those four points in particular, we were able to try and like filter through exactly what was going on, and every time we found a new one, it was easy to, include that into the documentation because of the structure
Lori-Lee: That sounds almost as complicated as my video file naming structure.
James: Almost.
Lori-Lee: When it was filmed? Is this final Rev one? Rev two. Final two.
James: Yeah. A lot of it, yeah.
Sofia: . Lori-Lee, what are your continues.
Lori-Lee: Well, my continue was very similar to yours with these contracts, whether it's NASA or anyone else, I think you should always try to release some kind of MVP the initial contract in that initial phase one, even if they don't ask for it. And I think that's beneficial to you as the company and. the customer, to the government customer, like it was massively valuable, I think, to NASA that they got a usable app out of an initial, like R and D study. It also I think, helped with our competitiveness in the down selects, like when we were proposing. The initial project, you know, they're asking for a feasibility study and we're like, we'll, do you one better?
We'll give you a prototype or an MVP or something you can actually put your hands on. so I think we should definitely continue doing that. And I would actually say like, we need to continue doing that for every contract because there's no guarantee that you're gonna get past prototyping. So for the sake of your own business and your own product lines, like you wanna walk away with something that you can turn into a commercial offering, providing whatever you're building isn't restricted with, you know, being allowed to do that, most NASA products are not gonna be restricted.
So no problems there. And then you, you've already spoken about this as well, Sofia in some of the other sections, but looking for ways to apply XR technology, even if they're not asking for spatial or, or XR technology to try to dial in on what their problem is and then deciding can our technology address this problem? Because, you know, sometimes they don't know. What to ask for. Exactly. Or they're not allowed to say specifically what they want for a whole bunch of reasons. so those would be my, my two big continues.
Sofia: Yeah, and I would say, you know, look for ways to apply it with discernment. I feel like anyone, we are the ones that like, no, you don't need a headset for everything. Like, we're not that kind of, you know, XR enthusiast where you're like, you will do everything from a computer on your face. We're like, no.
James: Yeah, you took the words right out of my mouth. .
Lori-Lee: And I think the companies and or you know, small businesses and startups that come in with the perspective of we are a hammer and everything looks like a nail. Like our technology can solve everything.
Sofia: yeah.
Lori-Lee: a gazillion different topics across agencies, you're just gonna burn yourself out.
Like you're, it's, it's not sustainable and you, you're not doing yourselves any favors. So yeah, just be discerning about where. You decide to do that if they're not asking for your technology specifically. I think if any AI company is watching this, they're safe because everyone's asking for AI, so it won't matter, but other technologies, yeah.
Sofia: Not selling to the government, what are you doing?
Lori-Lee: Yeah.
Sofia: Because man, do they wanna need it?
James: Yeah, well, you know, I think that we are really good, you know, like we are discerning, as you said, and the thing that we always ask people whenever they start asking about XR technology in particular, I think we're pretty good about trying to voice the concern of like, yeah, but what is it that you actually want out of xr and like, what is it that you're hoping that XR is going to provide?
And do you understand the reality of what it's going to feel like being in a headset for an extended amount of time doing this work? Like there are things that are just useful in xr, like visualizing a lot of the three dimensional data that comes from space weather that's inherently three dimensional.
I. Or you know, some of the previous contracts that we've done that had to do with flight paths and things that are in, an x, y, and Z vector. But there are other things that I can think of immediately that would just be absolutely terrible in a headset, like having to do finances in a spreadsheet that sounds like some undiscovered circle of hell that I really don't want to be put in.
Lori-Lee: Yeah, I've never thought of that before. That sounds awful.
Sofia: I made a comment to Lori-Lee that I was like, I don't, you know, as a millennial I can do a lot on my phone. Like I can shop for houses, I can, you know, apply to stuff. You know what I will never do is like, do my taxes. I. What you need, you need the desktop for
Lori-Lee: Yeah,
Sofia: Right?
Lori-Lee: I.
Sofia: You know, form factor has to follow function and, this was a good use case, right? We are talking about 3D data, multiple sources, pulling them together into a single visualization experience and being able to look at the data sources and their different readings in the context of where they are in lower earth orbit.
So like, is there a reasonable explanation for why this satellite has a different reading than this satellite? Look at the distance between those two satellites, when. The solar flair happened, like the context was there, which I think is why this felt like a great one. But this is an awesome retro look at our start, stop, continue.
We have so many things that we learned. We have, we have grown as small business owners through this.
Lori-Lee: So what happens to this document now that it's done, does it live somewhere?
Sofia: Great question.
Lori-Lee: Mm-hmm.
Sofia: Great question. So generally you would keep all of your retros in the same place. If this were a sprint retro, you would look at it every sprint and then you would, you know, we would say, did we improve on any of the start? Stop continuing, right? You're particularly looking at the starts and the stops for us. Next time we kick off a project, we should look at the start, stop, continue, and not every project and every learning is going to be relevant, right? Like this was all related to Aura, which is one of our products. You know, kicking off a new project related to Katana. There might be some learnings that can carry through and some that don't. But the idea would be that in our internal kickoff, we look back at this document and we say, what of these start, stop continues? Do we need to bring in now at kickoff?
Lori-Lee: That makes sense. Yeah, and I remember actually like going back through the mental archives to my corporate days. That was actually the failing of lessons learned was we would do the document and it would go somewhere, go onto a SharePoint. You would never see it again. You would never sit down even at project kickoff and be like, Hey, let's review lessons learned from the last project. They're just like, nah. Like, they didn't know what they were talking about. Like, it's good, it's cool. We'll just, we'll just start again from day one. So
Sofia: Yeah.
Lori-Lee: A couple fail safes in here of the structure of sprints that would not just fall off the agenda. It's right here. Little line item. We'll pull up that file. So that's great. Well, thank you for setting this up and thank you for joining our retro. I'll leave links to our NASA app that's available on Quest. It's free. I can leave a link to this retro document in case you want to review it or make your own. And I will also link our winning NASA proposal in the show notes in case you're interested in applying for one of your very own. And if you enjoyed this episode, be sure to check out the previous episode where we break down the apparent death of the metaverse. Until next time, we'll see you then. Bye.
