Ship It Conversations: David Tuite on Backstage, Internal Developer Portals, and the Shift to AI Agents

Transcript

A lot of teams hear internal developer platform,

and they immediately think new portal, new dashboard,

new interface. But that is probably not where

this is going, because the real problem was never

just we need another place to click. It was always

too much friction, too little context, too many

handoffs, and too much time between idea and

production. And now with AI and coding agents

starting to change how work gets done, that question

gets even sharper. If developers are spending

less time clicking through dashboards and more

time working with agents, then the platform layer

has to change too. It has to become less about

UI and more about context, automation, and safer

paths to action. Hey, I'm Brian. I work in DevOps

and SRE, and I run Tellers Tech. This is Ship

It Weekly, where I filter the noise and focus

on what actually matters when you are the one

running infrastructure and owning reliability.

Most weeks, it's a quick news recap. In between

those, I do interview episodes with people building

tools, running teams, and thinking hard about

where platform engineering and DevX are actually

headed. Today is one of those conversations.

I'm joined by David Tuite, founder and CEO of

Roadie. a managed internal developer portal built

on Backstage. And this one is really about what

IDPs are for, how teams should think about them,

and how that changes as agentic workflows become

more normal. We talk about the difference between

a platform and a portal, the three big problems

teams are usually trying to solve with an IDP,

why adoption is often more of a human problem

than a technical one, and why a lot of teams

should start with automation first, not just

a service catalog. We also get into self -hosted

backstage versus managed backstage versus more

opinionated SaaS options. What trade -offs actually

matter there? And why the future may be less

about single pane of glass dashboards and more

about packaging the right context for humans

and agents at the moment they need it. And maybe

my favorite part of the conversation is that

David does not really answer this from a hype

angle. He keeps bringing it back to something

a lot more useful. Talk to your users. Define

the real problem. solve what painful is, and

do not build a platform strategy around a fantasy

version of the future. If you like these kinds

of conversations, follow the show wherever you

listen, subscribe on YouTube, and check out shipitweekly

.fm or tellerstech .com for more episodes, show

notes, and everything else that I'm building.

All right, let's jump in. Today, I'm joined by

David Tuite. He's the founder and CEO of Roadie.

Roadie is a managed internal developer platform

built on Backstage. And David's got a strong

take on where IDPs go next as coding agents become

normal. David, thank you for joining me. No problem.

Thanks so much for having me. Yeah, I've been...

kind of around the IDP space since its genesis,

I guess, about five or six years ago. I was originally

a software engineer and then an infrastructure

product manager at Workday. We built a IDP internally

inside Workday before IDPs were a thing, before

Backstage was open source, before companies like

mine existed, obviously. And so we kind of learned

some of the lessons through that process. We

experienced the pain points of why people want

to have an IDP. And when I say IDP, what I mean

is internal developer portal. as opposed to platform.

But yeah, we experienced the pain points of why

you would want one in the first place. And that

was what gave me the impetus to start Roadie originally.

Give me the thought behind platform versus portal.

Yeah, well, the way I differentiate them... is

kind of around the goal of what they're trying

to provide. So platform, I think about being,

as being deeply integrated, like vertically integrated

throughout the stack. So it's not just the visualization

of what's running and where and so on, but it's

also the orchestration. It's what is deployed

where, how do I move it to something else? And

it'll try and control that entire stack. Whereas

a portal, I think, and this is not necessarily

true, but as a general rule is a thinner layer,

which is trying to sit more broadly across more

of your stack. So how this manifests itself really.

With a platform, you often have like a pretty

high initial setup cost where you literally have

to move everything onto the other platform. Whereas

a portal should be more able to kind of work

with whatever you've got, integrate with the

tools that you already have, and just give you

a unified interface across all of those tools.

So if a team was deciding between self -hosted

backstage versus a managed backstage or another

IDP, what signals do you think matter most? So,

I mean, well, let me maybe take it back a step,

if you don't mind. and talk about why you would

want to have a developer portal in the first

place. So, because if you can answer that question

first, it's usually a good place to start when

it comes to which solution should I have, right?

But typically, and this is, I recommend that

people do this all the time, but try to define

the problem first. And so what I see out there

in the marketplace, and this has been broadly

true, I think, for the past five years that Backstage

and other technologies have existed, is... three

different problems or three different categories

of problems, I would say. So the first one is

that what I would call the discoverability problem.

People feel like there's too much software. There's

too many humans producing all of this software.

And it's just difficult to answer basic questions

about, you know, where are the bills for the

XYZ service? Does it even have bills? Who would

I go to ask in the first place? And obviously

that... That extends to, or the complexity of

those questions is multiplied by the number of

different tools that you're using, the number

of services that you've got, the number of humans,

and so on. And so that becomes a problem in and

of itself. Really, what you're trying to do there

is get the right context to the right humans

at the right time. And we'll talk about this

later on, but that problem is probably changing

quite a bit as we become more agentic. The second

category of problem is around speeding up the

path to production. Really like speeding up the

time it takes from an idea in a developer's head

to a service which is actually running in production.

There's typically, I mean, back when I was at

Workday, we had a 40 -page Confluence document

full of checklists that you had to go through.

Teams talk about ticket ops a lot. Most operations

require opening a Jira ticket against the platform

team and waiting for it to be done. You want

to kind of take away all of that. and essentially

provide self -service automation to the developers

who are running their software on the platform.

And then the third category of problem is really

about putting guardrails in place to ensure that

software which is running on the platform meets

a certain set of requirements, right? So this

could be simple things like, you know, if you

want to have your software running on our platform,

you should have a readme in the repository, right?

And it can extend to far more complicated things

around using the correct Docker base image, let's

say, that the platform team has just released

to run your software on the platform. And really

that's about improving homogeneity, trying to

make it a more consistent environment in the

platform. to improve reliability and stability

and speed. So those are the three kind of ways

that people typically explain their problem when

they originally come to me. And that's the job

of an IDP is to try and solve one or more of

those problems for a team. Does that make sense?

No, totally. So with those three areas of focus

in mind, is there a overwhelming majority like

common? problem statement that you see over and

over again? Yeah. Well, they typically always

have the discoverability problem. So they'll

have that problem first and then they'll have

one or more of the other problems. Now, it varies

a bit in terms of size of company. So firstly,

for IDP purchasers, they're typically 100 engineers

plus. That's the kind of minimum size of company.

Now, we do have smaller customers and there are

smaller teams out there who want IDPs, but to

really be successful or really have the pain

that an IDP can help you solve, you want to be

100 engineers or larger because you want to have

a certain size. is a certain amount of complexity

in order to be able to, in order to need to purchase

a platform or a portal to solve the problem.

But after that, it's really kind of maturity

specific or it depends on the maturity of the

team, right? A lot of the time, if they're a

new platform just getting started. or if they're

trying to migrate from a legacy platform to a

new platform, then the top priority for them

will be the automation pieces. It will be speeding

up the path to production because that's pertinent

for the job, the initiative that they're trying

to complete at that time. We see a lot of teams

also who are moving, let's say, from Bitbucket

to GitHub or Azure DevOps to GitHub or something

to GitLab, et cetera. And so they want to provide

automation to their teams in order to speed up

that migration. And so they'll be less interested

in the catalog and the discoverability pieces,

but they'll be more interested in the automation

pieces. So it depends a little bit on what the

initiative is. That's kind of why one of the

first things I'll often ask teams when they come

to Roadie is, What is the initiative? Why is now

the right time to bring in an IDP? Why wasn't

it six months ago? What's going on in the company?

And really that informs the IDP that you choose,

the features of the IDP that you want to roll

out first and how you want to use it and how

you want to communicate it to your teams. Cool.

So I know that I want an IDP. I've figured out

that problem statement. Maybe I need a service

catalog or I want that automation. How do I decide

between port, roadie, backstage? You know, where

do I start? Yeah, yeah, yeah. Well, I mean, regardless

of which platform you're going to have to choose,

and there is a way to think about that also,

you want to think about how you're going to get

it into the company or how you're going to drive

adoption of it. uh throughout the company right

so so i mean this is often much more of a human

problem than a technical problem i think and

people underestimate that so the if you take

a simple question you're gonna know you're gonna

want to have a catalog in your in your in your

developer portal that's typically the piece where

a lot of the functionality hangs off you know

you go and look at a service and then you can

see who owns it or you can redeploy it or click

a button to do something right So how are you

going to populate your catalog is one of the

first things that I would suggest that people

think about. The two paths that you have there

are some sort of automated population where you're

essentially going to connect it up to GitHub

and pull in the repos and connect it up to Argo

CD and pull in the applications from there. And

it makes form some sort of relationship between

those two things. That's going to be good for

catalog completeness, but it's going to be poor

for... giving the teams a sense of ownership

over how their service is represented in the

IDP because they'll feel like you just did that

work and it's nothing to do with them really.

The other end of the spectrum maybe then is backstage

is kind of traditional YAML files where you're

asking teams to put a YAML file in their repository

and maintain that over time. which is the other

end of the spectrum. It gives them a high sense

of ownership, but it's going to be less up to

date. There's going to be a lag between changes

happening in the real world and changes being

represented in that YAML file. And there's going

to be a slower rollout there because you're asking

teams to do something. But those are both ways

that we've seen be successful. But even beyond

that, you have to think about what is our data

model in this company? And that can often be

a hard thing to pin down in the first place.

before you even try to define that in YAML files

or in code or however you're going to do it.

You can get your architects in a room and talk

to Bill and talk to Mary, and the two of them

will disagree about what constitutes a service

in the company, or is the payment service part

of the payment system or the billing domain?

What is the nomenclature that we use to describe

the company, right? These are all things that

need to be decided at a human level before you

can dive into choosing your IDP, I think. You

would be surprised, or I think a lot of people

who maybe work in smaller companies would be

surprised at the level of chaos that exists out

there around some of these operations in larger

companies. We have plenty of customers who can't

answer a simple question like, what's a team?

If they go to Workday, they'll see one definition

of who's on a team. If they go to GitHub Teams,

they'll see another definition. And these things

mean... They're not incorrect. It's just that

in different contexts, what you would call a

team is slightly different. Maybe, you know,

your manager in Workday is a certain person.

And so you are in that team, but you're also

on call for a service which is actually owned

by a different team. And so you're kind of in

that team too, right? And so the messiness of

human environments really takes a toll when it

comes to organizing your data model and keeping

everybody happy. And so I do think that teams

should... think deeply about how they're going

to do that before they get an IDP at all. Other

good things to think about are what is your first

feature? What's the first problem you're going

to try and solve with your IDP? Which I think

can have a large effect on whether or not the

initiative is successful. recommend that teams

start with the automation use case in backstage

-based deployments or in Ro. The reason being

that catalogs have network effects effectively,

right? When you take some time to build out your

catalog and in those initial stages, when people

go to visit the catalog, they're not going to

see the things that they need. And so they're

going to be discouraged from adding their own

software. It's kind of, it ends up being a bit

like a social network, like Facebook or anything

else. Whereas automation has immediate ROI. If

you can take a process that used to take a month

and you can make it now 15 minutes, then you

can very easily multiply the amount of times

that that process is run by the time saved. And

then you can easily explain that to your VP of

engineering and claim a win and take that forward.

There's no waiting period before you achieve

that benefit. So we recommend people start there

a lot of the time. Of course, taking into consideration

the actual needs of the organization. If you

don't have a need for automation, don't start

there, obviously. But then, okay, so after all

of that happens, you've decided that you do have

a real use case for an IDP. You've thought a

bit about how you want to roll it out and so

on. The market, I like to think about, kind of

divides itself on a spectrum of extensibility

to ease of use or speed of deployment, let's

say. So at one end of the market, you do have

self -hosted backstage. It is, and let's be clear,

self -hosted backstage is the market leader.

Like probably 90 % of the market is using self

-hosted backstage. 3 ,500 companies out there

who have adopted Backstage from the largest companies

in the world to small teams of 10, 20 engineers.

The thing to keep in mind about Backstage, though,

is that it's a framework for building a developer

portal. It's not a developer portal itself. It's

kind of funny to think about, but back in the

early days of the Backstage community, I noticed

that there was a trend of people searching for

Backstage Docker container or Docker image on

Google because people were looking for not a...

TypeScript library, a bunch of TypeScript libraries

that they could build together into a developer

portal, but they were looking for a Docker container

that they could just run. And so one of the first

things that we did in the community was actually

just build that Docker container and make it

available. But that was a long time ago. Things

have moved on quite a lot. from there. But the

core nugget of truth is still true. Backstage

is a framework for building a developer portal.

You mentioned just before we started the call

that Spotify had said that teams should be six

to eight engineers dedicated to Backstage to

be successful for it. Our data shows the same

thing, really. And we ran a survey last year

called the State of Backstage. And when we analyzed

the data from that, people who reported being

very satisfied. with their self -hosted backstage

deployment had at least three engineers dedicated

to it. That's kind of what we saw across the

market. So that's all true. Time to value you're

expecting to see is six to 12 months. This may

have changed recently with the development of

AI probably has come down in the past three months.

I feel like Opus and improvements to Codex have

really increased what AI can achieve. So that

might come down a little bit. But the core work

that you have to do is still there. It's about

going and talking to your internal developer

community, distilling what they need. turning

that into features. A lot of that work you still

have to do. Building in things like role -based

access control, which doesn't come with Backstage

out of the box. You know, this is all kind of

boring stuff that I think at least we would claim

that your engineers are better off not doing

and just using a kind of existing solution instead.

But you do have Backstage, self -hosted Backstage.

That's at one end of the spectrum. It's going

to be the most extensible thing that you can

get. No matter what your internal tools are,

no matter how homegrown or legacy they are, it's

going to be able to integrate with them because

you basically build your own developer portal.

then at the other end of the market you have

port cortex etc um really what you're trading

off there is control for reduced time to value

so you're going to get more features out of the

box You're going to get things like scorecards,

role -based access control, built -in AI, et

cetera. All those things are going to come out

of the box and you're going to be able to just

use them on day one. And then when you're trading

off in terms of control is vendor lock -in, restrictions

to the amount of integrations that they provide.

You kind of are locked into their roadmap. Same

as with any other SaaS solution, limited customizability,

et cetera. But it's going to be more opinionated.

You're going to get started more quickly. And

so that's a path that you can go, of course.

Roadie is slightly different, and I don't want

to turn this into a sales pitch for Roadie, but

just to explain, because we are based on Backstage,

we give every customer a full Backstage stack,

but then we build in the kind of ease of use

that you need on top of it. So, you know, adding

integrations is just a matter of dragging and

dropping things around the place. There's no

re -employments. We give people search, which

is based on open search. role -based access control,

scorecards, et cetera, all those things are built

in. So the idea really is just that you're getting

the extensibility of backstage, but you're also

getting the ease of use and the reduced time

to succeed that you will get with port recording.

So speaking to the automation angle, how do you

think agentic workflows change IDPs or how they

may be implemented going forward? Yeah, I think,

I mean, we're in the middle of a massive shift

right now. I mean, I don't know how much you

can, how much you're perceiving it. I still am

hands -on keyboard writing code whenever I can,

you know, which is typically just my spare time,

but I'm making small changes. I'm not allowed,

the engineers don't allow me to make changes

to the actual products anymore, but I hack on

our marketing website whenever I can. And, you

know, I haven't written a line of code in maybe

three months or so, since Christmas, I would

guess. Everything is produced by Claude. So there's

a massive shift happening right now. I think

that IDPs existed to try and bring information

from external sources, LaunchDarkly, CircleCI,

whatever tools you're using. into one UI so that

you could have a kind of a single pane of glass

experience. You know, that's what people would

talk about a lot. I think that the need for that

is shifting. At least I feel now like I want

to be in my terminal or in Visual Studio Code

or whatever it is that you're using all of the

time. And I feel like the information can come

to me. So I think that's one huge shift which

is happening. Why would I go to a catalog and

click through an interface? to find a service,

to be able to see a piece of information when

I can just ask the question directly in my terminal.

So, I mean, that's how I think the shift is being

pushed onto the market. And so the UI layers

of IDPs, I think, are becoming less and less

relevant over time. So that's one change. And

then the other thing that we're seeing, and we're

a little bit earlier in this, but the more and

more work is being done by agents. And I don't

just mean when you're in cloud code. plug code

as an agent, but I mean an actually externally

triggered, hey, something went down, an agent

fires and makes decisions about what to do about

that. So these are operations decisions. It could

be, you know, add a second cluster or something,

right? We're earlier in that, but my expectation

certainly is that that is going to become more

and more prevalent over the next two years or

so as we can trust OLMs more and more. obviously

it's a lot riskier but the earlier stages of

that i think are are humans or humans building

working directly with llms quite closely to answer

questions you know i mean take an example of

something like figure out why the payment service

went down last night between 3 and 4 a .m right

like that's an actual use case from inside and

roadie that we were discussing recently but if

you think about the context that's required there

for the agent to be effective it's What is the

payment service? Where is the logs for it? What

log group? Where is the metrics? Which cloud?

What region? Etc. There's so much context that

an agent needs to be able to be successful. So

I see the job of... IDPs shifting a little bit

from providing context to humans through UIs

that they can click through to providing what

I would call context bundles to agents so that

they can have historical data if they need it,

real -time data if they need it, concise, accurate,

correct, to be able to make decisions about how

certain changes in the environment should be

reacted to. So building like a centralized MCP

for all? information around the development cycle

i think that can i think that can certainly be

part of it yeah um that will give you the kind

of real -time access to well let me let me let

the agent ask a question to be able to get a

result right i think that's certainly part of

it i think that i'm not sure that that solves

the entire conciseness part of the problem and

it certainly doesn't solve the kind of historical

data or what has changed over the past hour part

of the problem But certainly that will be involved.

Yeah, for sure. So if coding agents make dev

faster, why wouldn't DevX teams suddenly have

time to build whatever, everything? Yeah, well,

I mean, I guess like I would be, the engineer

in me would be hopeful for a world where they

would. But I guess the CEO in me is not necessarily

sure that that's how it's going to pan out. You

know, I mean, it certainly does make it easier

to make changes, faster to make changes. That's

irrefutable at the moment. But I think that.

That doesn't necessarily mean that an internal

platform team is going to have all the time in

the world to build whatever they want. I worry

that people in the C -suite are going to look

down at that team and think, well, okay, now

we can actually take two engineers off that team

because everybody else is more productive and

put them on the revenue -generating side of the

business. I still think that that fundamental

tension between the revenue generating side of

the business and the platform team or the internal

teams still exists. And I still think that trade

-off exists. And so it's not necessarily clear

to me that you're going to have more time to

work on internal projects. I still think that

even with AI, I mean, the return on investment

equation does change, but I still think it's

difficult to prove the benefit of that or prove

that return on investment. to the executive level.

So this is a challenge that we deal with a lot

in the IDP space because IDPs are at their highest

level supposed to improve productivity of developers.

But we're not even all that good. And I mean,

when I say we, I mean the industry at large is

not all that good at measuring productivity of

developers in the first place. So showing a delta

between where it was before and where it is now

is even more difficult. And I still think that

that's going to be true as well for internal

projects, even with AI. You can obviously claim

the cost is reduced, and that's true. But the

cost reduction mostly... shows up in the front

of the application build -out lifecycle, right?

So, you know, it's easier to get started. It

still gets a bit slower to improve software over

time, or it's still slower than it is to start

a Greenfields project. I mean, we see this with

backstage upgrades internally, right? One of

the benefits of Brody is just that you don't

need to upgrade backstage anymore. But AI is

not all that good at upgrading a sprawling backstage

application, making broad changes across the

code base. And so that's still going to be true

if you build your own. and out of software. Scope

is going to increase over time and you're going

to have to do wide changes internally. And that's

still, I think, going to be difficult. And then

the other large source of waste that I see inside

software engineering organizations is not necessarily

not building the thing fast enough, but it's

building the wrong thing in the first place.

And I still think that that's going to be a problem.

I don't think AI necessarily tells you what to

build or how to solve the pain points of your

users. And so one of the benefits of... I think

picking off the shelf software is that it's built

out of the lessons which have been learned over

many, many years from rolling out at lots of

different companies and solving all sorts of

problems that you don't necessarily want to slow

yourself down by having to reinvent the wheel,

solve those problems again. So, okay, given that

it sounds like we're moving from dashboards to

workflows, IDPs become... the source of truth

for context to some degree, which I think is

an organic move. What should teams do now so

they're not rebuilding everything again in 18

months? Like, how do we prepare? That's a million

dollar question. I wish I had the answer to that

myself. It seems like everything you put in your

roadmap might get released by Anthropic six months

from now and might disappear, right? I think

you have to stay close to your users. I have

to, and I feel this too, right? Because as a

startup founder, you somewhat... have to live

in the future, right? You're trying to keep track

of what's happening out there in the world and

what's coming in the next six months. But I have

to go back and put every idea through the filter

of, well, where are our customers now? And I

think that internally, if you have internal customers,

which is what a typical platform team has, I

think you need to keep that in mind too, right?

Like, what are the needs of the business right

now? Where are my users? What are they capable

of? What does our security restrictions and our

governance rules and everything else allow us

to do? I kind of build for now with an eye on

the future. I think, you know, I guess some myself,

I still think that developers are going to be

around for quite a while. And this is, again,

just pure speculation on my part. Nobody really

knows, but I certainly feel like the human and

AI loop. is is quite important and will be for

for the next while i think we'll be augmented

by ai i think it's a bit like having an exoskeleton

you get stronger you get better um you get faster

but i still think that the creativity part um

exists and and will do for quite some time the

state of dorametrics report end of year last

year um i thought it was interesting they talk

about how engineers in general say that they're

getting more productivity out of ai or with ai

but yet we're not actually seeing like more tangible

deployments or like feature rich work being deployed

where engineers think that they're getting more

more out of ai but they're maybe not you know

or at least not as quickly as we would think

that they should maybe with the efficiency gains

yeah Yeah, well, I think, I mean, this is, again,

just personal thoughts. So frame this however

you want. I think that it's tempting to do more

busy work now, I think is the first thing. Like

things that where you wouldn't have necessarily

made, you wouldn't necessarily made that feature

before, but now because it's easier, now you

will. But that doesn't necessarily add to like

the bottom line, the overall productivity. I

think the developers who are able to make product

decisions have gone up in value. a lot over the

past three to six months as well. Because again,

the AI won't tell you what to build. It will

build it faster. So I think if I was going to

give advice to someone who's starting out in

software engineering now would be to try and

be a well -rounded individual who knows some

UX, who knows some... UI design, who understands

why people use the software, because then you

can kind of build towards your customer and you

can actually solve problems in a very real way

for people versus just moving code around, which

I think is a risk. And I think there's also just

a, there's a general economic diffusion problem

that we have to solve at the moment as AI just

percolates through the economy over the next

couple of years. So, I mean, an experience I

had recently was we had a, we had a full company

offsite. And we're a remote company, so it's

rare for people to all be in the same room together.

But we got the technical people in the same room

as the non -technical people. And if you're not

on camera, you can't see that I'm doing air quotes.

But the air quotes are because I feel like everybody's

a bit technical now. It was eye -opening for

some of the non -technical people, people in

customer success, people in sales, etc. Eye -opening

for them to see what the engineers were able

to do in a very short amount of time with AI.

And I'll give you a great example. I mean, one

of our customer success people went, took the

lessons from that offsite, you know, just kind

of, it was, when I say lessons, it was more of

an eye -opening experience. It was just, oh,

wow, that's what you can do. And once he'd been

shown what was possible. He was able to go back

and he's never written a line of code in his

life, but actually make his own customer success

dashboard, which pulls information from lots

of different sources and shows the health of

each of our customers, etc. So I think there's

a certain amount of just realization of what's

possible that has to happen throughout the economy.

The models don't need to get much better, although

they will. the knowledge has to percolate through

the economy. And I think that that's when you'll

see the real productivity gains. Yeah. It's almost

like we're all becoming managers now and we're

all like the skill set is really knowing how

to prompt an AI, but then also how to be critical

of the output of the AI too. Like, because it's

very, it's very good at being confidently incorrect.

So if you don't give it the context, like you

said, it's going to make assumptions, you know,

so you have to know how to. how to actually reason

about what it's giving you and then be able to

give it the right input so it gives you the output

that you're expecting. Yeah. And just because

you can build anything and everything doesn't

mean you should. Yeah. We've all used bloated

software. I mean, it's one of the top complaints

of people who actually produce software when

software is bloated. But, you know, AI can help

you make your software bloated much more quickly

than you could before. Very true. Okay, so wrapping

up, what's one piece of advice for platform or

DevEx teams starting an IDP this year? Put your

laptop away and go talk to your internal users.

That's fair, yeah. Right? You know, go and ask

them, hey, what are you doing for 90 % of your

day? What's the biggest frustration you've got?

What takes the longest time? Because you might

find out that it's actually, well, the bills

are slow or whatever, right? And it's not that

they're trying to search for who is. the owner

of the payment service or who's the manager of

that team or whatever else. I think go talk to

your users. That's the number one piece of advice.

If you actually are in a situation where you

want to have an IDP or you have a need for an

IDP, I would suggest trying a little bit of self

-hosted backstage, try a pure SaaS solution and

try Roti just so that you get a good overview

of the market. An IDP is something that you are

going to roll out across your entire organization.

You're going to live with it for quite a while.

And so you want to put some thought into that

decision. It's not necessarily the most reversible

thing in the world. So I think just take a look

at a couple of different solutions and see how

they each perform. Yeah, that's fair. Where should

people follow you or read your stuff? I'm probably

most active on LinkedIn, which almost makes me

shudder to say. The inner developer in me hates

that, but it's probably true. So just search

for David Tuite on LinkedIn. Yeah, that's probably

the best place. Very cool. I'll leave all that

information in the show notes as well. David,

thank you for coming on. Really appreciate it.

Super. Thank you very much. Thanks for having

me. All right. That's my conversation with David

Tuite. My biggest takeaway from this one is that

the future of IDPs probably is not build a prettier

dashboard. It is building the right context layer.

For developers, for platform teams, and increasingly

for agents. That means discoverability still

matters. Automation still matters. Guardrails

still matter. But the shape of the experience

is changing. Less clicking around for answers.

More workflows. More context delivered where

the work happens. More systems that can help

humans and agents make better decisions faster.

I also liked that David kept this grounded. He

was pretty clear that teams should not start

by chasing hype. or by building towards some

imagined 18 -month future that may change again

in six months. Start with the pain you actually

have. Talk to your internal users. Figure out

what slows them down. Figure out what causes

friction. Figure out what should be self -service.

Then build from there. This is a much healthier

way to think about platform work. And honestly,

it is probably the right way to think about AI

too. Because just because we can build faster

now does not mean we automatically know what

is worth building. If you enjoyed this episode,

follow Ship It Weekly wherever you listen to

podcasts. If you want the full show notes, links

to David, Roadie, and the resources we talked

about, head over to shipitweekly .fm. Thanks

for listening, and I'll see you later this week.

Ship It Conversations: David Tuite on Backstage, Internal Developer Portals, and the Shift to AI Agents

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

👤 Guest

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

Get the next episode in your inbox