Unlocking the Power of Custom Software: Building Tailored Solutions

Jason Bittner:
Hello, I’m Jason Bittner and welcome to our Helix Insider podcast. I’m joined in studio today with three of my team, Senior Developer Sam Sheldon, Senior Developer Andy Webster and our Senior Systems Engineer, Shawn Coover. Hello everybody.

Jason Bittner:
Today we want to talk about custom software development and how it can benefit you and improve your company’s productivity. Here at Triple Helix, we make custom software applications for our clients all the time.

Sometimes having something custom made is a huge improvement to a company’s workflow and productivity. So, I wanted to start with you, Andy. How do you prepare for a custom project?

Andy Webster:
Well, usually we start with… Some specification of what the project is supposed to be and really the more detail, the better that is for the project. The more we know what you need and the more detail you can provide the better.

If you provide vague detail in the beginning and then kind of, um, pin down things later going on, it usually means doing things over. So, um, when we have like a really clear picture of this is what we need to do right off the bat, and this is, and this is kind of a guideline of how we’re going to accomplish it, that makes for the best end result.

Jason Bittner:
Makes sense. Sam, how about yourself? How do you prepare for these projects?

Sam Sheldon:
Yeah, so like Andy said, starting with the specs is important. One thing that I always try to get a sense of from the customer is what their process is currently. Because I know that a lot of the time when we get requests for custom software, we’ll go to a customer and they’ll say, yeah, we don’t like our current process and we’re going to revamp it and this is going to be the first step of that. And that never seems to turn out quite like they want it to. I assume because it’s too much change all at once. You’ve got a bunch of people used to doing things a certain way, whether that’s with Excel spreadsheets or on paper or whatever else their process might be, whiteboards, things like that. What I’ve found is it’s important to look at what the process that they have currently is and try to match that as closely as possible while also getting a sense of where they’d like to go.

Because that means we can build something that’s flexible enough that if their process changes to something more streamlined or to include more features that we can give them, that it’s a smooth transition rather than, as Andy mentioned, having to rework things.

Because reworks cost a lot of time and energy and there’s always something, some little thing that goes wrong and gets forgotten.

Jason Bittner:
That’s a good point. Um, you know, you touched on a very excellent point where, you know, we are relied upon by our customers to create a specification that fits their need. And very rarely is the customer writing that specification for us, but on a rare occasion, a customer will actually be able to do so. Andy, tell me about a time where we had one of our customers who really knew what the process of this was and how they handled giving us their spec.

Andy Webster:
Yeah, it’s a specific customer that I’m thinking of that is always very, very detailed in their specs. And I really appreciate that. It makes things a lot easier because it takes the guesswork out. They have all the specifications just lined up for you. It actually makes a really big difference because that means less time back and forth trying to hammer out all the details. Because the more work you put into it as the customer, initially, the better the results are really gonna be because we’re gonna have a better idea of exactly what you want. And you can still fudge things around a little bit after that because sometimes you don’t really know what you want until you actually get the paint on the canvas. But… Yeah, that particular customer always provides just really, really detailed specifications. And I feel like that is part of why their products turn out so good.

Jason Bittner:
Yep, and that’s fair. I mean, like the best customers of ours, I can provide very succinct details of what it is they want. And they usually get a much better product at the end of the day. So we talked about getting ready for a project. Now let’s talk about diving in. Sam, talk to us about what it’s like now that you have your specification in hand.

What’s it look like when we actually formally dive into the application and start creating the code?

Sam Sheldon:
Yeah, so usually our first step is we have our standard template for starting a project. We’ve got tools that we use, frameworks we install, things like that. We get that basic layer laid down. And then we usually start with a big general feature and then we drill in on that feature and work through that usually until it’s done.

And then… repeat with the next feature and the next, and test as we go, things like that.

Sometimes there are some projects that are a lot more interconnected where we have to do a whole bunch of different parts of it all at once. Those tend to be the ones that are really complicated, like full applications rather than the ones that are just, we need an extra reporting layer on top of our existing ERP. Yeah, it kind of depends on the project, how we get started, because reporting layers on top of ERPs are very different than an entire, you know, application that’s meant to support your process from start to finish.

Jason Bittner:
Right, good point. And I know a big part of our diving in and getting started is related to not only the software itself, but the environment that it runs in. And I know you, Shawn, are a big part of our team in making sure these environments are stood up correctly and actually configured correctly.

Tell us an example, Shawn, about a project you worked on where that made a huge impact for the customer.

Shawn Coover:
Well, we have a manufacturing customer who has a lot of sensors in their manufacturing plant and we designed and developed a platform to take all the data from those sensors and aggregate all that data and combine them into one database.

Jason Bittner:
This is OEE or operational equipment effectiveness, or also referred to as IoT, internet of things. Is that correct?

Shawn Coover:
Yes, correct. Correct. But we also had to design and develop a platform for a server to aggregate all of that data and provide that to the custom application that we built for the customer as well.

The architecture and the platform that the application is built on and the container and the server that it’s on is… very important in my opinion.

Jason Bittner:
Yeah, that one was very, very impressive because I mean, there are a lot of software platforms off the shelf that you can purchase that will do this for you, but they are extremely expensive, both from a setup and a maintenance standpoint.

And this particular customer was looking to not use one of those custom or rather off the shelf systems.

And because we had already developed a fairly robust reporting platform for them, they wanted to hook in. And I remember your input with this, we were basically taking the sensor feeds off of the floor with specific hardware and then wrote the architecture to allow us to contain that.

And then of course reconnected to the application stack because there were multiple, multiple touch points, not just the sensor hardware but other reporting and whatnot we did. That was a very impressive project.

Shawn Coover:
Yeah, yeah, I had a lot of fun with that. It was a good challenge getting all the sensors all aggregating through the wireless gateways and getting it all aggregated into the server. We’ve got a big database that’s rolling. And the reporting portal that we built for them is… is pulling data from that database.

Jason Bittner:
This is a very good example of where a custom software application was really what this customer needed. The off-the-shelf hardware, software stacks were going to be very cost prohibitive for them.

And quite frankly, may not have even worked for exactly what they wanted. So yeah, that was a really good job, Shawn. Now I want to take a pivot here and talk about, we’ve talked about how we set up for a project and get things ready, the specification and the server environment.

We talked a little bit about diving in and actually doing the work itself. But now I’d like to talk a little bit about how we actually wrap up.

So when a custom software application is deployed, what does it mean to have that application continue to function properly and get support as the customer takes ownership of it? And Andy, I’ll turn back to you on this one, what do we do when we wrap up and do a final delivery?

Andy Webster:
Yeah, so typically what we do is we’ll set a date for the release and we’ll get all our scripts prepared, all of our stuff. If there’s any data to migrate over, we’ll have that all ready to go. And usually the client will specify a time of day that they want it to happen at. Everybody will get out of whatever application that we’re migrating data from, any kind of stuff like that. And then we’ll launch the application.

And typically, right before that launch, we’ll have acceptance testing. So we’ll have a beta test. So that’s where a larger group of people will come into the software and behave as if they were doing their regular business activities. And if that passes, then we will release the software and we’ll be kind of on standby if anything acts unexpectedly, if you get any bugs, things like that.

Usually, as like any software release, anywhere, this always happens. You always have something that… There’s always something that nobody thought about. We’ll jump in there and fix those things up really quickly. And then as time goes on, those things will be less and less.

And it’ll be more like maintenance in the sense of, if anything is not behaving the way it’s supposed to, it’ll open a ticket with us and we’ll fix it. Or if they want to extend it, then we’ll open a ticket and add something new. But yeah… That’s pretty much the process that we go through releasing.

Jason Bittner:
Sam, you’ve been on quite a few wrap ups, as I would say, where the application is now being delivered and handed off. Give an example of a project that you worked on where you really were happy and pleased with the end result and what that looked like for them.

Sam Sheldon:
Yeah, so I think maybe some time ago, we had a project that after a lot of development finally launched into production, we’d done a bunch of testing with the users. It was, you know, we were all pretty confident this is gonna work. So we get it launched and then they start doing their financial reporting through our software.

And they realize something’s not adding up quite right. So they call us, obviously in a panic, something’s wrong. And so we had to go through and figure out where the problem originated from, what specific part of the financial reporting wasn’t working correctly.

And it actually ended up being a case of, they had requested a specific thing to update their processes after we had gone live. But of course, over the course of development, plans change and this was forgotten about.

So we had to go through and rework some things within that reporting to ensure that their old methods still worked. And I believe eventually they did update things to the way they had planned, but it was still very awkward and required a lot of you know, a lot of very quick bug fixing at the very end of that project.

Jason Bittner:
I recall it. I recall it a specific way where like they had after a year of testing not actually caught this particular feature bug. It was one of those hair on fire moments when you launch. This is a very large lift for this company.

They had quite a few people doing the UAT for the live production launch to make sure everything was working right and then that moment where they were like, oh no, we realized we didn’t tell you were supposed to use this set of instructions and then it was like you had within the context of a few hours to fix everything.

Sam Sheldon:
Yup. Yeah, it was definitely hectic. And it’s fully possible to miss things in testing because there’s functions of your business that you don’t think about outside of tax season or outside of when you do a specific type of audit or whatever.

There’s a lot of little things that you don’t think about when you’re just looking at your day-to-day processes. And of course, if it’s not something you think about very often, when you’re doing your user acceptance testing, you may not even think to go test it because it’s not something you think about every day.

Jason Bittner:
So, our Senior Systems Engineer, Shawn Coover, we honestly like to refer to him as our battle sergeant because he just takes care of all of the problems on the servers.

And Shawn, love to hear from you. Give us an example where did a launch and the lift had been made, and then all of a sudden something’s horribly gone wrong and what we did to remediate it, especially on your end on the server side. Because if something bad is going to happen, it’s going to happen on the server. and the configurations, right?

Shawn Coover:
Right, right. You’re definitely right about that. I’m trying to think about a client where the deployment with the configuration went all wrong. I can think about one customer who was using a… I guess they were migrating their website to a new platform and it required two different servers.

And originally we had only spun up one server with one platform. But after that, we realized that we need a separate server for another service. And we had to quickly spin that up and get that up and running for them.

Jason Bittner:
How much time did that take us?

Shawn Coover:
Um, we deployed the website within, I would say two to four hours, we had the second server all spun up and ready to go. It was a hair on fire moment.

Jason Bittner:
Yeah. And this is speaking to what happens when you do your launch, all best plans intended, but they don’t necessarily go the way you want. And I like your example because I remember that particular client, um, you know, having the redundant solution able to be spun up that quickly against their production environment.

This wasn’t like us putting it back into development and shutting everything off. It was like they were live and they needed this other service stood up. So that kind of speaks to like your ability of spinning up these servers quickly in the pipeline and the tools that you’ve created to do so. Yeah. No, that was very impressive.

Shawn Coover:
Yeah, I really enjoyed developing and designing the server platform that we’re using right now at Triple Helix. It’s really fine-tuned for the applications that we develop for our clients, and they’re really customized.

We have a base image, but each application, as custom as they get, the image itself is going to get that custom too. So we have a base image, some great architecture, and we can just dive down there.

Jason Bittner:
Right. So that speaks to the idea of custom software development as a whole. You know, like a lot of people think custom software development is costly and very labor intensive.

And what we here at Triple Helix have done is we’ve tried to take that labor intensiveness and costs out of the equation by standardizing application stacks, standardized server, standardized processes. In fact, right from the beginning, as we started this podcast, the specification is key. If you don’t know what you’re going to build or how you’re going to build it, it’s going to actually create a problem for you, not just the client, but actually for us as well, the development team.

So, well, I think that’s almost all the time we have for us today for the Helix Insider podcast. But just before we wrap up, I’d like to get some closing thoughts from everybody. Andy, closing thoughts?

Andy Webster:
Yeah, be specific as possible, I would say, and clear and constant communication is the best way to get the best product in the end.

Jason Bittner:
Yep, agreed. Sam, closing thoughts?

Sam Sheldon:
Yeah, so Andy’s correct that being clear and consistent is a good way to get what you’re after. I’ll add that when you’re developing a custom software solution, that’s maybe not the time to be aspirational about changing everything at once. It’s hard to change everything.

Jason Bittner:
For sure.

Sam Sheldon:
Start with what you know, have us develop something that fits with what you know and let us know where you’re going so that we can plan to eventually get there.

Jason Bittner:
Good point. Shawn?

Shawn Coover:
Yeah, speaking on what Andy and Sam spoke on first, having a specification is amazing. If you know what you want, then we can definitely design and develop not only the code, but the architecture that supports the code in detail that’s going to really support it all.

And then having clear and consistent communication for what you need going forward and making these changes in… phases instead of having it all change at once so that you can step into all the changes.

Jason Bittner:
Yeah, absolutely. Um, so, you know, I’d like to invite our listeners, if anyone is currently experiencing a roadblock or, or has an idea for an application that would help their company, uh, would really love to chat with you, please put the, your feedback in the comments below, or also please feel free to reach out to us.

We’re on the web at www.3xcorp.com. Also, (860) 490-3488. We’d love to hear from you. This is Jason Bittner from our Helix Insider podcast, and I wanted to say thank you to my guests, Sam Sheldon, Andy Webster, and Shawn Coover for their great insights on custom software development. Until next time, thanks everybody.