Making Salable: Inside the startup for SaaS entrepreneurs

So, what's the process behind actually building Salable? And what's in the pipeline for Salable in the near future? We spent some time with colleagues from the Salable Engineering team to find out.

Jay: I'd say we use a version of scrum. We work from tickets in Jira, we have daily stand-ups, and so on. We're agile, but fairly flexible about it. Being a small-ish team, we're pretty good at self-organising and we generally operate on a 'do the right thing' mantra while keeping each other accountable. Right now we're transitioning from the proof-of-concept startup phase to a really slick, well-planned product, so we're starting to formalise our work a bit more as we grow.

Luke: I guess I'd call it 'pragmatic scrum'. I think we take the helpful parts; we use Jira and plan things into epics and, loosely, sprints, but we don't get too terribly bogged down in all of the intricacies. I've worked in teams that get really stuck on all the minute details and I think that defeats the purpose!

Jay: Exactly, it's a balance. It comes back to 'do the right thing' again for me. It's a trade-off between having the meetings and doing the planning we need to do, but also avoiding putting too many strict processes in place, so we can still move fast and just get stuff done.

Jay: Well, the short answer is we primarily use the industry-standard stuff—TypeScript, Node, React, and Next.js. We're always looking at new, edge-case tools, but it's tough when you're trying to build something production-ready that you could be using a framework or a tool that's just going to disappear. It's caught us out in the past, so to some extent you have to trust what you're using. I also don't think you need to change what works.

Luke: That's true. I think it's all about using the right tools effectively.

Jay: To go into it a little more, the landscape of development tools has changed so much over time. Once you'd have been writing, say, HTML in its raw format, and that's how you built things. Now there are so many tools and frameworks for everything that the output is sort of abstracted away—and now you've got AI as well, and you can actually remove all of that and just ask AI to output something! It really is about using the right tools for the job—any of us in the team would go and learn a new language or framework if we needed to.

Coner: Not so much one specific thing, but when we find a problem, we really just all put our heads together to talk about how to fix the issue. Eventually, we'll come to a conclusion between us. It's a lot of team problem-solving. A lot of bouncing ideas off each other.

Jay: I would say it's also similar at the business unit level. As a growing startup in a wider organisation, some of the other business units are ahead of us in their journeys on certain things, so we can learn from them. We can collaborate with them on, say, how they've worded certain policies, and how they're hosting their apps, things like that. We might not solve everything right away, but we work on it collaboratively across The Adaptavist Group. That's a big benefit of having a larger organisation's backing—we're coming at things with the combined knowledge and experience of a business that's been around a lot longer but with the speed, energy, and new ideas of a fresh startup.

Luke: I think a good example of how we approached something specific would be the new onboarding flow that we've worked on in Salable. I think it showcases how we work pretty well—and that 'move fast' startup mentality that Jay mentions. We found some data that showed that only a fraction of people signing up were actually taking the next step we'd intended during onboarding. We discussed the problem and came up with a plan for a guided onboarding experience. But we work in quite an iterative way, or at least we strive to. So the first version that we released, just last week actually, was functional and very usable, but it was essentially a basic version, an MVP (minimum viable product). We'll iterate on that and improve over time—so yesterday, for example, I put up some improvements, and more will come as soon as tomorrow or even later today. We essentially try to solve problems in the simplest, quickest way, but continually improve as we go. It means we can get something out the door, try different things and get feedback, and then tweak it from there. The alternative would be more like putting all of our eggs in one basket with one big solution and kind of just praying that it'll work when it's finally deployed—not such a good experience for our users.

Jay: We have so much more coming! A lot of it is around UX, the usability and flexibility of the app. We've had it out there a little while now and we've seen people use it, and like Luke said, we're taking that data and we're figuring out where people are getting stuck. One big thing that we're also in the planning phases for right now is re-architecturing a whole chunk of how we actually do subscriptions and licensing. I won't say too much about it, but it's going to really grow what we can offer. We're not just a subscription payment processor!

Alice: Sounds promising. I guess we'll have to watch this space! Thanks for chatting to us today.