Season 2, Ep. 11 – It depends: Choosing a tech stack with Deividi Silva and Wade Williams

Transcript

Faith (00:04):

Well, guys, we’re talking about something today that Deividi and Wade kind of deal with every single day – just by nature of our business – which is, how can founders who are not technical themselves make really good decisions when it comes to, specifically, their tech stack early on in their business? And we see this all the time, right? We’ve got find founders who come to us and say, I need an XYZ developer. And we say, Well, what are they doing? And they explain what it is they’re doing. And in fact, they do not need the XYZ developer. They need somebody totally different. Deividi, I mean, you probably have what, a dozen of those conversations every month?

Deividi (00:46):

I’ve seen it happen in the last year, at least a couple hundred times. Yes. Yeah, it’s very fun.

Faith (00:54):

So you got some reps in, we got some experience here. And Wade, I mean, same with you. I know obviously here you’ve made almost every technical decision. We haven’t done a major migration, I don’t think, since you joined, but obviously the product has evolved and required a lot more of those kind of base level decisions since you joined. 

Wade (01:18):

Yeah. I mean, our product has been relatively stable, as far as stack decisions go, for a couple years at this point. But there was some initial ones on the front end there early on. When I started, it was a bootstrap front end style sheet CSS framework. So we moved from that to Tailwind and mostly ‘cause I wanted to use Tailwind, which is—

Faith (01:44):

That’s an okay reason. 

Wade (01:46):

Spoiler alert. We’re gonna try and say “it depends” as few times as possible, so maybe we can have like a little Mario coin every time “it depends” comes up.

Faith (01:56):

I wanna highlight those moments, ‘cause I feel like those are the inflection points that founders or whoever’s responsible for the build needs to be aware of, rather than, you know, saying/doing whatever the internet says they should do or an investor says they should do to kind of mark those points where you guys say, well it depends and make a note. Like, I need to talk to probably a senior developer about this, right?

Wade (02:20):

Yeah, for sure. And I mean, you know, I’ve got some high level advice that we can get into here as we kind of go on with it. But, you know, at the end of the day, I think it just comes down to who you can find to do the project and what the requirements are, and it’s all trade offs from there.

Teja (02:38):

Hmm. I would be curious to know, why do so many people come to the table with an agenda of requirements in terms of skills? Like, you know, is it because somebody told them, or is it ‘cause they do research? Or…

Deividi (02:59):

It’s very common that someone told them, Hey you’re building an eCommerce, so you should look into all of these things that are around PHP, and I don’t know, you should probably look into WooCommerce, or, I don’t know—things like that it’s fairly common. Someone told them or they did a quick Google search, but in fact, what you wanna look in, one of the main points of having someone technical assist you with those conversations—you wanna take it to a higher level, right? What is it that you want? What is the customer problem that you’re solving, and what is more important to you, one thing over the other? It’s always going to be a trade-off, and that’s always the way that discussions should be directed. That’s how I see it.

Faith (03:55):

You said something interesting Deividi, which is, you know, you should always have someone technical to do this work with—at least the initial kind of brainstorming and decision making. And Wade, you said like often, your stack depends on whatever that dev wants to work on. So I’m curious, how do you choose the right person to be your advisor in those early stages? What do you look for?

Wade (04:19):

It’s a great question. I mean to be honest, a lot of the times what’s gonna happen is, you know, founder wants to do thing, is hanging around with x crowd of people, winds up meeting y person, y person is an expert in given the thing that becomes the de facto tech.

Deividi (04:37):

Well, if you don’t know anyone, just try to find someone that you like hanging out with, because you are going to spend a lot of time with that technical person bouncing ideas back and forth, so if you at least like this person to begin with, odds are that you’re going to the right direction. 

Teja (04:58):

Do most of the companies that come to us in this stage, where you have to kind of advise on technical trade offs and stack—do you feel like they’re informed properly about that? Or are they just—like why is the person that helped them make that decision not at the table?

Devidi (05:20):

Right. And that’s one of the things that we always try to get to that, right? If you come into the table with data, with one firm idea about how it should be, but you present yourself to us as not being technical, Hey, where’s the technical person that decided this? Can you bring this person to the table? We wanna talk to that person. Because at the end of the day when we’re presenting developers so they can hire, that person is going to do the technical interview, is going to be working with them on a daily basis, so we need that person to come into the table so that we can articulate those more technical questions, and we can understand a little bit more about the problem that they’re solving.

Faith (06:07):

I think one consequence we often see of making an incorrect decision when it comes to tech stack early is— I mean, naturally this is a part that we see as the hiring piece, right? They make the decision. If they don’t have a technical advisor like we offer on the front end, they make the hire in the incorrect stack. That developer gets in, and they’re like, this is absolutely not what you need and I don’t actually know the technology that you need to be using. I’m not familiar with it. And so that’s an expensive mistake, because you’ve gone through the hiring cycle, you’ve gotten somebody onboarded and your code based. What are some other consequences of making an incorrect decision up top with your tech stack?

Wade (06:49):

I would kind of qualify this as like, not necessarily an incorrect decision, but it’s an irreversible one. Not that it necessarily cannot be reversed, but reversing it is going to be hard and will be painful. And what typically winds up happening in those situations is that reversing the irreversible decision becomes the thing that nobody ever wants to do, because it’s so painful. And so this probably isn’t exactly answering your question, but a lot of the times that I’ve seen that wrong decision made up front is not so much like a tech stack insofar as like, should it be Ruby or Python? It’s like our problem space is reselling books from people, and we sell them back to Amazon, and they sell ’em to us, and we’re gonna do that with a WordPress plugin. And it’s like, okay, that’s a way you can do that. But when you start digging into the requirements there, it turns out like you need a lot more software than what a WordPress plugin is gonna do for you with like a WooCommerce situation.

Teja (07:58):

Do tech stacks get invented to solve business problems, or is the evolution of tech stacks mainly developers trying to solve technical challenges for themselves and trying to solve business problems? Like why does more than one main stack exist?

Deividi (08:19):

Depends on what level of abstraction or what level you— (Wade: Ding!) you are thinking about programming language, so it can get pretty academical. So what—in the academy, what kind of problems, what kind of papers are getting out, and how people are researching that. So that with that comes the new programming language from that. And you can see all of the things in the past, well, everything—you think things are new in terms of programming languages, it’s really old. Most of the things that you think are new are probably 10, 15, 20 years old. And they come up from that and also from big companies that have big problems that need to be solved differently. So those are the main drivers for this innovation in this area. For frameworks though, it’s more like, Hey, I’m building—I wanna build something slightly different here that attends to my needs, so I’ll do this in this different way for a specific JavaScript need that is actually not something that everyone is gonna need, but for me it solves the problem in a better way.

Wade (09:39):

Mm. Yeah, it’s a good chance to make a shameless plug. So when I started with Gun on our app, the folks in place had created not an API framework that purported to be an API framework to solve all of our API framework needs. And so just in the natural course of improving that, we now have an API framework that’s available on the internet that’s open source that anybody can contribute to. And the reason that we decided to go that route is because the 10,000 pound gorilla in the Jango API space is called Jango Rest Framework. And it’s kind of like a big ball of stuff-and-things and is not as slim and precise as what I’d prefer to see. So out of that, we have a new API framework at Gun.

Faith (10:29):

Called Worf, correct?

Wade (10:31):

Yeah, that’s right.

Faith (10:32):

I am realizing as we’re getting into this conversation, we probably should have started with basics, because I always assume that the audience is technical, but in this case, you know, we’re probably talking to a lot of non-technical folks. So when we say tech stack, what do we mean?

Wade (10:47):

All the technologies that you’re using, from operating system to backend language to backend framework to database technology to front end CSS land, style sheet frameworks, bootstrap tailwind to that kind of nature. And then your front end framework, as far as like, JavaScript, is basically gonna be the answer there, but in certain edge cases, it won’t be. And then there’s a million JavaScript frameworks on top of that. When you’re talking about mobile apps, you’re looking at iOS, you’re looking at Swift, you’re looking at objective C, you’re looking at Android, Java, et cetera. And also, it could be as rudimentary as like what platform you’re running on AWS—if you’re hosting your own infrastructure, if you’re running on Lin, or what have you.

Faith (11:32):

So again, for folks listening who are nontechnical or maybe just getting started, there’s probably infinite combinations of those technologies. Certain technologies tend to play nicely with each other, so you’ll often see a similar stack for a certain technology. But, you know, when we’re hiring dev teams, that’s why it can get so complex—because even if you’ve got some experience with html, CSS, you know, JavaScript frameworks, there’s a lot of edge technologies as well that will kind of impact who you need and when. 

Teja (12:13):

I’m curious about what are the dimensions—let’s say two people want different stacks. How is that dispute arbitrated? Is it around ease of use? Is it around trying to hone in on the business problem? Does it just depend? You know, or is it like, I worked here and I know their shit better, so that’s what we’re doing—‘Cause this is what we used at my old job?

Deividi (12:41):

Oh yeah. So you got already got the “it depends”.

But what I’ve seen is there’s a culture element to the company, right? You can see the folks that come in earlier. There’s definitely that thing of seniority and having all the context of business decisions that were made that led to that path. So you cannot take that for granted. It’s very common to see the people that it gets hired, and they wanna bring in the stuff that they learned somewhere else, and they don’t try to get into the context of that decision, right? I bet thousands of folks that got hired in the first years on Facebook, they were like, why is everything PHP still? We are at this size, and still everything’s PHP. We’re doing a hundred different things to overcome the fact that we’re still PHP, right? But we gotta understand the context. The company was growing, and a lot of companies are like that—growing in a ridiculous space—and that’s impossible to change some of the things and just keep doing, doing, doing and delivering, because delivering solutions is more important than just going back and change everything again and again. So it’s a big (inaudible), but that does play a factor of people not understanding the context of the decision that was made.

Faith (14:11):

I feel like the truth is that because there’s kind of so much that goes into your stack, you’re never gonna— every hire you make isn’t going to be an expert in every single language and framework that you use. And we see that a lot with companies who are hiring. Like, okay, this is a must have, these are nice to haves, they can kind of learn these on the job. Are there any, in your experience, any front or back end languages that you would advise a founder do not choose that? Because it’s really hard for folks to become acquainted with it who aren’t an expert already.

Wade (14:48):

Outdated things that should be dead, like COBOL. But I think really what you’re getting at is like, when you’re making a decision around what the stack is gonna be like, the number of developers that you can find to operate within that stack definitely plays a role. So, if you’re gonna go out and find some esoteric new language that hasn’t yet gained market penetration, that’s probably not the right decision.

Deividi (15:14):

Think about the business—again, the business problem that you’re solving. I think we saw one example, I don’t remember when, a few months ago was interesting, because the founders I think that were requiring the Phoenix framework and working with Elixir and all the early VM and all of that stack, there’s a reason you go that route, right? You have high concurrency. It’s a different type of applications that you wanna use that. But if you have no reason other than, hey, this first person knew this and we wanna experiment and continue with that, maybe for those ones, try to go back a step and think about, Hey, should I approach this on a different ways? Do I really need some something so powerful for this kind of small business problem that I’m solving or more common business problem that I’m solving? I always try to think about that. Am I really using the tool that is commonly used to solve this type of problem?

Teja (16:32):

Can you guys think of a company that made a tech stack decision and that decision proved fatal to the life of the company?

Deividi (16:40):

I don’t remember anything like that. You can see a lot of like banks stuck on old mainframes and old programming languages there, and they need—well, they’re not gonna die because of that. They’re not gonna go away, because they’re banks. They have a lot of money. But they need to pay ridiculous amount of money for someone that still know those kind of things and is able to fix things in production. So that can get really expensive, if you end up in a situation like that.

Wade (17:15):

The survivorship bias there is probably the thing that makes that question hard. There’s probably been a ton of companies that died because of bad tech decisions, but there were probably a hundred other bad decisions that went along with the tech decision that didn’t necessarily directly implicate the tech decision. But, you know, as an example that kind of lends a little bit of insight, Twitter probably had the wrong tech stack there for a long time. ‘Cause there was a period in Twitter’s life where they were constantly down. But they had enough money to work through that problem, and now they have super, super reliable operations. 

Teja (17:51):

Yeah, that’s interesting. Maybe the tech stack decision cascades into an HR difficulty of recruiting the right people, which then cascades into a set of business solutions from a technical standpoint that aren’t optimal. And then so on and so forth. 

Wade (18:10):

Yeah, and the ones that I’ve seen in my career, where the company eventually wound up dying or going out of business or something is—it’s not necessarily that it was the wrong tech decision, but it was the wrong decision to continue down that path with that tech for too long. Because again, a lot of the times that it’s like the wrong decision is not necessarily something as simple as language, but it was like, well we started with this PHP forum and started modifying it and then built a community website out of that and then got a bunch of investors, and now it’s like completely not even close to the thing that they’re marketing or trying to make happen. And at some point you gotta rip that bandaid off.

Faith (18:48):

Makes me think of the the parable that we talked about in your last interview, Wade, where it’s like, instead of fixing the broken thing, it’s a cent cost fallacy. So you just build around it until you end up with this thing. 

Wade (19:03):

And then it’s hard to retain talent.

Faith (19:06):

Oh, yeah. Because no one wants to work in that. What about no code? Like when would we advise a founder to pursue no code rather than, you know, traditional tech stack?

Deividi (19:17):

Founders, non-technical—I would love if they start doing things before—like trying to solve the business problem—whatever way they can, strong bias for action, go and do something. Spreadsheet, no code, just go and do it. Just go try to fix the problem, get some money moving, get your first few hundreds of dollars, and then you start adding those problems of trying to understand what is the proper tech stack that you wanna put in place. Just find your customers, solve the problem for some people—ok, I have a business, now I’ll try to find a perfect stack—so hundred percent, those things are here to stay and more of that, if possible. 

Wade (20:11):

A concierge approach to getting the business off the ground—and I mean that’s what basically Gun did. I mean, there was an inkling of a website, and there were some jobs published, but at the end of the day, it was like a lot of back office humans doing all the work to make sure that things happened. And it got to a point where, okay, well this is worth investing and building out the thing to make all this human work not as necessary.

Teja (20:34):

Yeah. And I will share, that’s definitely been a growth area for me, because I think, you know, when we kind of grew the business, we took that sort of no code approach where it was like, hey, let’s—spreadsheets. I mean, the business ran on spreadsheets and on lever, basically. And then transitioning to a product. I think actually I remember in the early days, I really struggled with caring about the difference between setting the direction and then being involved in how to solve the problem. And that that is like an area of growth that I have definitely experienced. And I think a lot of non-technical people that ultimately do have the responsibility of the solution being implemented struggle with,  because they’re trying to reconcile the need for accountability and ownership, with the inability to actually do the thing. So they have to give space for the thing to be solved in whatever direction that it’s solved in. That’s challenging. It’s really challenging to get there. And maybe that’s some of the resistance that non-technical people have when trying to decide a tech stack is like, well I should care about this thing. I’m responsible for it. But then they don’t know all the context, you know?

Wade (21:58):

Right. And you know, maybe you guys have more experience with this—with folks who have come in looking for no code, but if somebody’s looking for a developer for their no code platform…

Faith (22:07):

It’s not doing the thing it’s supposed to.

Wade (22:09):

Probably time to not use the no code platform.

Faith (22:12):

That’s a good litmus test. I think Teja, what you were talking about with founders who want to be, you know, they’re non-technical founders or not developers themselves. This is a question that Abbey sent us, and I think it’s a really good one to cover, which is like, for these founders who do wanna learn and want to be at least familiar with what’s going on in a technical layer of their business, how would you advise that they do that without getting in the way of their developers?

Teja (22:47):

This for me?

Faith (22:48):

For anybody, Yeah.

Teja (22:50):

I had to lean on sort of like, the human element of trust and being able to sense integrity, and then once you feel confident that you’ve made a high integrity decision in partnering up with somebody, then you have to be disciplined enough to trust their decision making. That’s it. You know, and that’s pretty psychologically difficult I think, but like, that’s the only way. Like, you just have to trust that they’re making the right trade offs and you have to trust that you’ve communicated the business needs sufficiently.

Deividi (23:22):

If you take balances and apply to the other side—if you have the technical person, they completely need you to—trust you that you made the right decisions. They’re gonna question, they’re gonna verify, they’re going to trust—but verify, if they’re smart. But that right, there’s the other side too, because I’m gonna build something for you, and I wanna believe that we’re doing something that is meaningful, but I need to trust that you already understood, so I can go talk to the customers, so I can go in and do my thing and create all this code. And it’s interesting too, because—this side is interesting too, because you have a lot of technical people that, hey, I have all these skills. I can move mountains and put things into place, but I don’t know what problems, what business problems people have and what they need to do. So you have that side of people with all the technical skills that just don’t know how to use it.

Faith (24:29):

As two people who advise folks on how to choose a tech stack, what would you recommend that they prepare in advance of those advisory conversations? Like what do they need to bring to the table so people like you can give them really solid advice around tech stack to choose?

Wade (24:48):

Evidence of their idea. Working in reality is a big step in the right direction. ‘Cause a lot of the times, like in those early days, people have a lot of ideas, but they don’t have a lot of evidence that any of it works the way that they’re suggesting. And again, that’s where it’s good to run the concierge business on, you know, SquareSpace, or something like that. And, you know, use as minimal amount of tech as possible. There’s an old quote that you can think on for hours that says, “No software is better than no software.”Which, you know, I kind of take to mean, if you don’t have to fix that thing with software, then don’t.

Teja (25:31):

Interesting. 

Wade (25:32):

And so if it’s somebody who’s been running a business, and it doesn’t have the technology, then they’ve got a lot better sense of what it takes to run that business. And those conversations are gonna be way more informed than, you know, having some hypothetical map of what level of concurrency you’ll need a year from now. ‘Cause premature optimization is basically the root of all evil. So, you know, you don’t need to start with the thing that’s gonna solve for a million requests per second when you have zero customers. 

Faith (26:04):

I would assume some sort of inkling of like business model. I mean Wade, what you just said was like, all of that needs to be on the table. Like you need to understand your business model, you need to understand the business need that this software is solving. So that makes sense. And obviously like for different industries there’s different go-to’s, but I think there’s a lot of flex space within that, obviously it depends.

Teja (26:31):

So I think it actually might be valuable to go into why it’s actually better for a business to do things manually or to have the customer validation and the business model validation before automating it. Because you know, I think we all know why, sort of, but it might be helpful to just be clear about that. Like, it’s not ‘cause people don’t wanna do the work, there’s like a legitimate reason behind it.

Wade (27:02):

There’s no lack of people who are willing to do the work on a thing that eventually is not gonna work. You can pay a developer to work on something that’s never gonna work until you run outta money. And I’ve seen it happen, and it’s not fun at the end of the day. So yeah, I mean, it basically comes down to classic (inaudible) and startup stuff. I mean, you wanna validate the problem and as learn as much as you can about it and then back feed that back into the system and improve your solution and learn more and hopefully sell more and get the business to a point where, you know, you’re comfortable going out and hiring developers, because developers aren’t the cheapest.

Teja (27:36):

And even the style of work is very expensive, mentally. It’s like there’s a lot of labor associated with investing into automating a solution—less so than doing it manually. You know what I mean? And then it’s harder to unwind, too. 

Wade (27:56):

Yeah. It’s harder to unwind, a hundred percent. I mean, code has a maintenance cost associated with it. So I mean, generally speaking, if things are built properly, you can spin ’em up and put ’em in production, and they’ll run for like—until they don’t. But that day will come, and everything needs to get fixed. Dependencies change constantly. Things go out of date. Long term service cycles for operating systems are only a few years. Like, it’s gonna be full of security holes in a couple of years, if it’s not maintained. So there’s costs associated with all the code that you do write, and if it doesn’t do the thing that you want it to, then you need to have it changed.

Faith (28:33):

I also feel like it’s really easy for founders, especially founders who get funding early, like rather than pursuing a bootstrap business who—once they hire their initial dev team, it’s really easy to get stuck in the trap of like, okay, well here’s this feature idea or there’s this bug we should fix and just feeding your dev team work that isn’t actually moving the ball forward on the business. And it’s really hard to kind of take a pause and be like, you know what? My dev team isn’t gonna have any work for the next two weeks, but I need to rethink my business roadmap and figure out what the next most important thing is.

Wade (29:10):

In most situations, if you give your tech team no work for two weeks, they’ll find plenty to do. 

Faith (29:15):

Maybe they’ll build you a Rest framework.

Wade (29:21):

Either that, or they’ll work out some things that they don’t like about the way that the implementation works. Which is—basically, there’s always those types of work items that can go on in an existing code base.

Teja (29:32):

So, we’ve spent a lot of time talking about really early stage ideas. You know, I’m curious who—like as an organization scales—who actually in the organization is responsible for changing a tech stack or for making that call? Like, hey, this is not worth the squeeze anymore. Like how does that process even work? 

Deividi (29:55):

That’s a good question.

Wade (29:56):

Yeah. It’s tough, and I don’t think that you’re gonna find like canonical advice on this, but I’m happy to follow up—Deividi, if you wanna take a crack at it?

Deividi (30:05):

I’ve seen it different ways on startups and bigger companies, but mostly on enterprises. You don’t want your architects and people at the highest level to be worried about tech stacks. They’re going at the highest level possible, talking to the stakeholders, and understanding the trade off that they need to consider for moving business one direction and toward the other. And then they’re going advise all of the developers and all the teams, Hey, here’s the direction we are taking. We are are using a reactive framework for front end, whatever you wanna choose. If you wanna go angular react, I don’t care. This is the way we move forward because of this this and this business reasons, and moving forward on the back end for these reasons—and so that’s just more structure on a bigger enterprise. And when you talk about smaller companies, that should come from a CTO that’s always talking to the stakeholders and understanding that, and that’s where the direction comes from, and then it’s for the team to take that main direction and decide between them which specific technology they’re gonna use.

Wade (31:51):

Yeah, that’s a really good answer. In the enterprise context, I think the thing that kind of was unwritten is there might be way more—like number of tech stacks involved at that level could be near the actual limit of how many tech stacks there are, depending on like the overall problem space that they’re working in. So like, Amazon probably has a little bit of literally everything. Somebody’s probably using that. I think a lot of the times the change is organic, because it has to do with the developer experience being so poor that nobody wants to deal with it anymore. And that’s usually also coupled—or may or may not be coupled with some sort of pivot that the company’s undergone, whether or not that was something that was clearly articulated or something that slowly happened over time. So I’ve seen projects where to bring up the PHP forum software that turned into community site— example, like at some point that had entirely jumped the shark and could no longer support what the business was selling, because they were trying to then white label it. And it’s like, okay, so if you wanted this to actually work guys, like we really need to move the whole architecture over to something that’s gonna be able to support what you’re now going out and selling. And I guess there’s also a little bit of a gotcha there, because if you did build this tech too early, and you have a sales team that’s out selling stuff, a lot of the times it’s easy for that sales team to just put requirements onto the product in kind of a way that’s—I guess organic. But if you don’t have strong product management in that situation, you can wind up with a bag of worms pretty quick.

Teja (33:39):

That’s interesting. In my mind, I envision a scenario—and you guys can tell me if this is accurate—it’s like maybe a business, like a revenue stakeholder comes to the architect and is like, Hey, we need to go do this thing ‘cause some customers are asking for us to do this. It’s a big revenue opportunity. And then the architect is like, Cool, that makes sense to do that. We need to totally change how the way the product works, so that’s gonna take us 12 months to do that. And then there’s that tension there. Is that accurate or…?

Wade (34:10):

It’s happened for sure, and I mean okay, Joel Spolsky has an article about how you should never do a from scratch rewrite. So you know, there’s that. But at the same time, Joel Spolsky also did a from scratch rewrite and created a programming language. So, you know. Yeah. I mean now we have an esoteric language that nobody understands except for the people who work here. So I mean, take the advice at its own face value. But yeah, I mean the from scratch rewrite thing is hard. And so I think the one thing that Deividi was kind of pulling at is it’s like to the extent that you can stand up this part of the system that’s now running the thing that we want, that’s gonna be more efficient and do kind of a slow replacement of slices of the system. That’s one approach that you can do, where it’s like you still have the fallback, you still have all the things that it’s doing, but you can offload pieces to a new system.

Teja (35:05):

How should a non-technical business stakeholder think about balancing technical debt versus revenue opportunity?

Faith (35:16):

Ask your developers, I would say.

Wade (35:22):

Yeah, I mean I think it’s probably its own whole podcast, but at a high level—so like, what’s technical debt? So, it depends. You know, one way to think about it is if your dev team is incapable of getting anything done, then that may be an indicator that you have too much technical debt.

You know, a lot of the times technical debt will show up as like—for example, with us, we’ve labeled clearly in our backlog items that are technical debt, and they range from things that we don’t like, things we know we could be better to things that we eventually should do to hire priority beyond that. And at this point, you know, after two and a half years or so of maintaining that backlog, we’re at a point where, you know, out of the 6,000 issues that we’ve created, and most of them are closed and a hundred something open, I think we might have 30 that are technical debt related. And we’ve got a milestone that’s gonna be coming up that will knock out like 15 of them that actually matter. So, I don’t know if that really answers your question, but it’s answer. (Teja: It’s definitely an answer!)

Deividi (36:36):

I think that one hit more personal to Teja. Teja really wanted to answer that one. 

Teja (36:44):

This is where I have to go back to my previous answer of this trust. And so I don’t need to fuckin’ get it— I just gotta know that the dude gets it.

Faith (36:55):

I think the litmus test is like, if your a developer can convince you one way or another, then that’s probably the way to go. As long as you trust who you hire.

Teja (37:07):

Yeah.

Deividi (37:07):

A smart architect can, if they don’t want to deliver anything to you for a year and just wanna tinker with something, they can definitely lead you to that direction if they want. So it’s all about trusting that everyone is aligned on the same business outcome there.

Teja (37:26):

Totally.

Deividi (37:28):

Right. So they will find the right balance if they understand what is important to the customer.

Teja (37:35):

You know, one of the things that I think I’ve probably learned a little bit too late, but I’m glad that I learned it: There is a cost to constantly aligning direction, and it’s a cost born by everybody. And so like you have to be really good about getting the right people on board and making sure that the vision is super clear. Yeah. And then after that, it’s like you just gotta go for it. 

Faith (38:02):

Well, that’s a great way to wrap up. You guys, thank you so much. 

Teja (38:05):

Give ‘em the last word. 

Faith (38:07):

That’s the last word. No, that was a great last word.

Alright guys, thank you so much. That was super informative, and I feel like we actually got into some really useful advice beyond “it depends.” So great work, you two. I really appreciate it.

Teja (38:22):

Yeah. I mean both Deividi and Wade, we met through the platform.

Faith (38:28):

Great plug, Teja.

Teja (38:31):

And all of the people they’ve hired have also come through the platform. So, you know, the way to meet really solid technical people you can trust is, you know, at least we found is through us. Yeah.

Faith (38:45):

And if you made it through this whole episode, and you’re like, I still don’t know how to choose a tech stack and/or hire developer, that’s why we exist. So come talk to us, and chances are, you’ll talk to one of the four of us pretty early.