What I've really been doing my whole career is looking at how teams work. Other teams, my own team, the wider IT org, and the lines between every org in the companies I've worked at. Where does the work get stuck? Where are people doing the same thing three different ways? What's slowing them down that has nothing to do with the job they were hired to do? Where are the lines of communication failing?

Then I take that friction out, so they can get to the real work.

I love making the lives of the people around me better. At work, that looks like removing bottlenecks. At home, it looks like building an app that tells me when the water filter is due. Same instinct, different address.

The work behind the work

Most teams don't struggle with the work itself. They struggle with everything around it: the hand-off nobody owns, the approval that waits on one person, the manual step everyone forgot was manual, the process that made sense three reorgs ago.

None of it is dramatic. It's a few minutes here and an hour there. But it adds up, and it's the part that wears people out. Nobody joined a team to fight the tooling, and nobody likes a process that doesn't make sense.

So when I look at a team's workflow, I'm not asking "are they doing their job?" I'm asking "what's in the way of them doing it?"

We're on the same side

Here's the part I care about most: the whole company is one team.

When one team is lagging in the way it works, it doesn't stay that team's problem. It affects everyone who depends on them, and it makes every project that needs both teams harder than it has to be. You can't work well together on a shared problem if you don't share a way of working.

That doesn't mean every team has to work identically. Each team has its own nuances, and those are often there for good reasons. But when the foundations are shared (similar processes, similar methods, and real communication between them), nobody has to reinvent the wheel, and everyone starts on a level playing field.

And when something needs attention, we lean in. We help each other. We're not competing teams that happen to share a company name on our résumés. We're on the same side.

From digging to watching

Here's one example of what that looks like in practice.

Audits like SOX used to mean digging. After the fact, someone had to work out which changes were in scope, then search through tickets, release notes and deployment history to confirm when each change happened and whether it followed the controls. Half of it meant ruling things out, based on history nobody remembered anymore.

At the time, that digging fell to me. I was the only one doing the auditing, so I knew the constraints well.

So we flipped it. Before our team onsite, I gave the team homework: the intro courses for our integration platform, MuleSoft. Then at the onsite, I challenged them to build automation that watches for in-scope changes as they happen and flags them right away. Now the digging happens while the change is fresh, and the people who made it still remember why.

The win wasn't only automating a manual task. Only one person on the team knew that platform. This took away two bottlenecks at once, me as the only auditor and them as the only MuleSoft expert, and it brought the team together to solve a real problem, learn together, and grow together.

It's the same work. It just moved from reactive to proactive, and that one shift took a painful, backward-looking job and made it part of the everyday flow.

That's the pattern I keep coming back to, in every system I touch: stop finding out after the fact.

I'm the cleaner

I've been the cleaner of a lot of orgs and systems. I love cutting out the fat.

The unused fields still being filled in by some automation that does things nobody needs anymore. The three tools that each do half of one job. The workaround that became permanent because nobody had time to fix the real thing. The pile of logic on one object that sets off circles of updates behind the scenes and slows down every page load.

Tech debt is real. It isn't a someday list or a nice-to-have. It's the reason the simple change takes a week, the reason the new person takes a month to get up to speed, and the reason the team is tired. It slows down every project that sits on top of it.

A lot can be said about preventing tech debt, and honestly, even with the best processes and intentions, it will always be a byproduct of the work. Something stops being needed. Something new comes along. The vision changes. Or we just tried a thing and it didn't work the way we thought it would. When that happens, whatever was replaced needs to be removed, updated, or at the very least turned off. If it isn't, that's tech debt.

Left alone, it makes the foundation we build on unstable, muddied with excess. Over time it becomes a hoard that takes more and more work to dig out of. And worse, when you finally go looking for something stable underneath it all, the core pillars of logic have often been eaten away or lost. I've seen it.

Tech debt needs a seat at the priority table, right next to the shiny new features, because it's the thing that decides how fast every one of those features gets built.

The same instinct, at home

This is why I build what I build on the side.

Saasy Logs exists because reading a Salesforce debug log shouldn't be a chore that eats your afternoon. DwelLogs exists because keeping a house running is almost always reactive: the pump quits, the filter is a year overdue, and you find out when something breaks. I wanted it to be proactive instead.

One of my mottos is see a need, fill a need. Most of the needs I see are friction: in a team, in a process, in a system, in my own laundry room. I can't help noticing it, and I can't help wanting to solve a good problem.

Once I've noticed it, my mind starts working. I want to understand it, and I want to make it better. For me, and for the people around me.

Because we're on the same side.

On a roadmap, that's one line: add sign-in. In practice it was a database, an email service, a domain's DNS records, an email template, four rounds on how signing in should work, and a whole layer for working offline. All of it on free tiers, because DwelLogs is free and I want it to stay that way.

Here's what's actually behind that one line.

The stack, and what it costs

• Supabase for the database and sign-in.

• Resend to send the sign-in emails.

• Porkbun for the domain and its DNS.

• GitHub Pages for the site and the app.

Every one of those is on a free tier. The domain is the only thing I pay for.

Free isn't the same as unlimited, though. Every free tier has a ceiling, and part of the work is knowing where each one is before you hit it.

The email nobody else could get

Supabase sends sign-in emails out of the box. I found out what that really means the first time I wanted someone else to try it: the built-in email only reaches people on your own project team, a few an hour. It's meant for testing. As long as DwelLogs used it, I was the only person who could sign in.

So DwelLogs needed its own email sender. I went with Resend: 3,000 emails a month and 100 a day free, far past what a test group sends, and it speaks plain SMTP, so Supabase only needs a few settings, not code.

Then comes the part nobody puts on a roadmap: DNS. For a sign-in email to land in an inbox instead of spam, the domain has to prove it's allowed to send:

• an SPF record that names who may send for the domain,

• a DKIM key so receiving mail servers can check the email wasn't altered,

• a DMARC record that tells receiving servers what to do when the other two checks fail (for now mine says: just report it),

• and an MX record for bounces.

All of it on a subdomain, mail.dwellogs.com, so sending stays separate from the address people write to. None of it is hard. All of it is fiddly, and one typo in a long DKIM key means nobody gets their code.

Branding an email is like building for 2005

Here's a catch I didn't expect: Supabase locks its email templates until you set up your own sender. The sign-in email couldn't even carry a code until all the DNS work was done.

Once it could, it had to look like DwelLogs. Email apps only read a small, old slice of HTML: tables, inline styles, no web fonts, no SVG. So the logo is a PNG the site already serves, the colours are the site's palette written out by hand, and it's dark text on a light background, because Gmail and Apple Mail darken emails on their own and that's the combination that survives it.

It's a small thing. It's also the first thing a new person sees from DwelLogs, before they ever see the app.

A link, a code, a pasted link, then just the code

This was the most surprising part, and it took four tries.

Try one: a magic link. Tap the link in your email and you're in. Simple, until you're on a phone. On a phone, every browser and every home-screen app keeps its own separate storage. The link opens in your default browser, Chrome on mine, while DwelLogs lives in the app on your home screen. You'd sign in somewhere you weren't.

Try two: a code as well as the link. You type the code into the app that's already open. Except the email template that needed to carry the code was still locked.

Try three: paste the link. The link already carries a one-time token, so you could copy it and paste it into the app. Except on an iPhone, pressing and holding a link to copy it opens a preview, and the preview uses up the link.

Try four: just the code. My own feedback, more or less word for word: just ask for the code, I don't want to do both. The app now asks for one thing: the code in the email. It works wherever DwelLogs is open. The link stays underneath, for anyone who reads email in the same browser they use the app in.

Each one taught me something about how phones actually behave.

No signal is a requirement, not an edge case

DwelLogs started at a ranch, and in rural places a signal isn't a given. The well, the barn, the back fence: none of them get a good signal. If the app stops working where the work happens, it's useless exactly when you need it.

So offline comes first:

• A save lands on the phone first. If there's no signal, it waits in line.

• Waiting changes go up on their own, as soon as the phone says it's back online, and every minute while anything is waiting.

• A hung request gives up after 8 seconds and waits on the phone, so a flicker of service never freezes the screen.

• Home tells you how many changes are waiting, so nothing is a mystery.

• Only the fields you changed are sent, so two people editing different parts of the same job don't overwrite each other.

There's one more catch: an iPhone clears a website's saved data after about a week of not being used, unless it's been added to the home screen. So the app now walks you through adding it, step by step for iPhone Safari, iPhone Chrome, and Android.

Say only what works today

The last step wasn't code. When sign-in changed how DwelLogs stores your data, some features on the site, like sharing through a Google Sheet, reminders, and invites, were no longer something a new person could actually use. So they came off the site until they were back for real. Invites are already back, in account terms; reminders come back when they work with accounts too. The homepage says what the app does today, not what it will do someday.

The unglamorous majority

When people picture building an app, they picture screens. Most of the work is the stuff underneath: DNS records, email templates, how a phone shares storage, what happens when the signal drops halfway through a save.

That's the work that decides whether someone can actually use the thing. Nobody notices it when it's right. Everybody notices when their sign-in code never arrives.

DwelLogs has accounts now, and it keeps working when the signal doesn't. It took a lot more than one line on a roadmap.

That's not a confession, exactly. I've been building on Salesforce since 2007: always in IT, always finding myself fixing, improving and hunting for a cleaner way to do things. Nineteen years of real applications inside a CRM.

I never went to college. I dropped out after a few months; I'd never wanted to go in the first place. I wanted to make things with my hands: metal sculpture, design, photography, woodworking. I wanted to change the world somehow through people's experience, using my own.

So I taught myself, and kept going. From nineteen until a few years ago I read many books, especially the O'Reilly Head First books nonstop (I own nearly all of them), along with object-oriented programming, ASP.NET, and lately chemistry, for no reason other than wanting to know. The hands-on dreams didn't go anywhere either: creating things, fixing, and these days a 442 in the garage. All self-taught, all for the joy of learning something and then using it somewhere else.

But a CRM's query language is a like a kids playground compared to a real one. You query along the relationships the platform lets you define, inside the limits it sets, and you learn to design around what you can't ask. That turned out to be excellent training. When you can't paper over a bad structure with a clever query, you learn to get the structure right.

So when DwelLogs needed a real database, I didn't start with the database. I started with the model.

The model comes first

My whole career, I've watched bad data make or break the application built on top of it. Not only bad input, the typo, the blank field, the "misc" category that ends up holding half the records, but bad structure. An object that tries to be three things. A relationship that should have been a lookup and became a text field. A shortcut taken in week one that every screen after it has to work around.

You can redesign a page in an afternoon. Changing the shape of the data underneath a live app is a migration, and it touches everything.

So before there were screens, there was an object model, and I worked on it until it was right. DevOps, Agile, years of watching what users actually do versus what we assumed they'd do: all of it pointed the same way. Get the foundation right, then build the pages that serve it.

I had a head start most product teams don't: I'm the user. I knew how I wanted to sort my own data. I knew what would make my own life easier, at a ranch with a propane tank at the top of a field, three fridges, and a drawer full of manuals that never say when. And I asked the people around me what they'd actually use an app like this for, because one user's habits aren't a product.

The goal was never "track everything." It was to take something that's usually reactive (the well pump quits, the filter's a year overdue, the dryer works MOST the time) and make it proactive. Easy to reach for. Quick to log. Telling you what's coming before it arrives.

Narrow is a feature

In a world of possible, everything looks like a feature. Calendar sync! Photo uploads! Sharing! Smart suggestions! Every one of them is a good idea, and building them all at once is how you end up with a bunch of half-baked ideas and no product.

So the first version has a line, and the line is the data, not the feature list. Get one person's real house into the model, make it fast and pleasant to use, and let the rest wait until the foundation can carry it. Photo uploads were actually built, and then pulled back out, because holding other people's files is a promise, and that promise waits until there are accounts to make it to.

Start with a spreadsheet, on purpose

The first DwelLogs storage was a Google Sheet. Not because a spreadsheet is a good database (it isn't) but because it's an excellent place to find out where your model is wrong. You can see every row at once and fix a hundred of them in ten seconds.

It was a test bed, built to be thrown away happily. And it taught me exactly what I needed to know:

• Which relationships hurt. Type a thing's name slightly wrong in a column that's supposed to point at another table, and you feel referential integrity instead of reading about it.

• Which fields nobody fills in. A field that's always blank after a few weeks of real use is a field to cut. No design meeting settles that argument faster.

• What a spreadsheet can never do. I had a setting that hid costs from someone you'd invited. It hid them on their screen. Anyone with the sheet link could still read every number. That's a UI convention dressed up as a permission, and only a real backend can turn it into a real one.

Choosing the database: evidence over comparison charts

By the time I sat down to choose, I wasn't choosing from a feature table. I was choosing against things I'd learned from real data.

• Firebase was out on a fact, not a preference. A new free project can't get file storage without a card on file, and a free app shouldn't need one.

• MongoDB was out on shape. A document store is the right tool for documents, and this isn't one. DwelLogs is relationships all the way down, and the questions I want to ask of it are plain SQL.

• AWS's free tier expires after a trial. A free app can't live on a trial.

• Supabase won: Postgres, sign-in built in, and row-level security, which is exactly the thing the spreadsheet could never do.

• Neon was a close second, and better on two counts: it wakes itself up where Supabase's free tier pauses after a week of quiet, and it keeps backups where Supabase's free tier keeps none.

Here's the part that actually decided it: both are Postgres. If either limitation ever bites, moving is a dump and a restore, not a rewrite. The best reason to pick a database isn't that it's the best. It's that the way out is cheap.

Sign-in isn't about keeping people out

This week I'm wiring up sign-in, and the framing that made it click was this: authentication is mostly about knowing who someone is, not about locking a door.

In the order you actually need it:

1. The same log on your phone and your laptop.

2. Jared logging as Jared, on his own phone.

3. Permissions that are enforced by the server, not just hidden on a screen.

4. Getting back in when you lose your phone.

Only the last one is really about security. The first three are about identity. And because it's an email link, nobody has to invent a password for a house maintenance app.

Balance is the whole job

Speed matters too. Every layer of cleverness in a model is a layer the app has to walk through before it can show you anything. Too simple and the model can't grow; too complex and it's slow and fragile. The craft is keeping it simple enough to make sense and flexible exactly where it counts.

That balance is the key to real change in applications, and it's the same thing holding most organizations back from AI. The tools are ready. The data usually isn't.

AI will build on whatever you hand it

Here's the funny part. Anyone can spit out an app with AI now. But an app built without understanding this crumbles fast, because the back end was designed by the same thing that's going to consume it and write code on top of it. If nobody who understands data shaped the model, the AI didn't either. It made something that looked right.

Real data is messy. How we collect it is messier still. And organizing data tells a story, whatever story you want. That's what happens with data collected by others: they pull out the story that serves their purpose and play it back with their own bias.

Keeping bias, false confidence and defensiveness out of an AI-assisted build is just as hard. AI is only as good as the context it's working in.

And that context is the data you. give. it.

The sentence was clean, confident, and wrong. AI helped me write that draft, and it did exactly what it's good at: it took what it had and made it read well. What it couldn't do was open the drawer. Only the person who lives here could catch that.

That's this whole post in one example.

I'm not anti-AI. I use it every day.

Let me be clear about where I stand, because this isn't a "robots bad" post. I build my side projects, SaasyLogs and DwelLogs, with AI as a daily working partner. It drafts, it researches, it writes the first pass of the thing I'd otherwise type twice. One of my mottos is work smarter, not harder, and AI is one of the smartest tools I've ever had.

But it's a tool. It lives on the utility belt, next to the grappling hook and the smoke pellets. Batman is the one who decides which one to reach for, when, and what the mission actually is.

What only the human brings

Here's what I keep running into, building real things with a very capable tool.

• Context. AI knows what's typical. You know what's true. It knows most houses come with manuals, or don't. It doesn't know about my drawer, or that the ADU runs on its own holding tank, or that one of my three fridges already moved out to the barn the ADU. The more specific the truth, the more it has to come from a person.

• Taste. The SaasyLogs logo is an S and L wearing sunglasses. We went through round after round on where the glasses should sit. At one point the design moved them up, and my feedback was simply: "no I do not like the sunglasses that high." No amount of reasoning gets you to that. Somebody has to look at it and know. We also learned to judge designs at full size. A call made from a tiny thumbnail preview nearly threw out the version we ended up shipping. It looked broken small and was fine at real size. Now the rule is written down: judge it at 1:1, with your own eyes.

• Judgment. When a copycat app showed up with a name close to DwelLogs, AI gave me a thorough rundown of trademark options. Good information. But deciding that roughly $1,000 wasn't worth spending right now, on a free app with no revenue, was my call. The tool can lay out the options. It can't own the tradeoff.

• Accountability. I have a rule in all my projects: never invent a number, and check how the number was produced. It's there because the failure I've seen most often isn't bad code. It's a confident figure in a summary that doesn't hold up once somebody checks how it was calculated. AI will confidently give you a number. A person has to be the one who checks it, because a person is the one who signs their name to it.

Leading with AI is still leading

Here's the part that surprised me: working well with AI uses exactly the skills I use leading engineering teams.

I keep a file at the top of my projects folder called "How we work." It says whose machine this is, what never goes into a public repo, how we branch, how we version, what accessibility means for us, and how I want feedback. It exists because context dies at the end of every chat, and re-explaining it every time is a tax.

Read it again and it's an onboarding doc. It's the same thing I'd hand a new engineer on day one.

• Clear context: what we're building, and why.

• Standards: what "done" looks like, written down, not assumed.

• Review: nothing ships because it looks right. It ships because someone checked.

• Permission to push back: one of my written rules is "Push back when something is wrong. Being agreeable about a bad number is worse than being blunt about it." I wrote that for the AI. It's also exactly what I ask of the people on my team.

The skills didn't change. The new team member did.

For the people we lead

This is the part I care about most as a manager.

AI should take the drudgery out of the work, not the people. The best use of AI on a team is removing the toil nobody wanted: the boilerplate, the status summaries, the fourth reformat of the same data. If that frees your team up for the hard, human problems, that's a win. If it's quietly used to make people feel replaceable, you'll lose the people you most need to keep.

Juniors still have to learn why. AI can hand a new engineer a working answer. It can't hand them the understanding they'd have built by getting there. As leaders, we have to protect the learning part. Pair on it. Ask why does this work? Review the reasoning, not just the output.

Team health matters more now, not less. People are watching how their leaders talk about AI. They can tell whether you see it as something that helps them or something that replaces them. That trust is the job, and no tool on the belt does it for you.

The belt is full. You still choose.

Work smarter, not harder. I believe that more than ever.

But smarter includes knowing when the tool is wrong. It includes opening the drawer, looking at the logo at full size, checking the number, and making the call. AI is the best thing I've added to my toolbelt in years.

It still isn't Batman. We are.

Great, I thought. Then I opened them. Every one tells you how to install the thing and what the warranty covers. None of them tell you when to do anything, or how to figure out what's wrong when it starts making a new noise. There's no schedule and no troubleshooting. Nothing says "check this before you call someone."

I've spent almost twenty years building systems that tell teams what's due, who owns it, and what it'll cost. Yet there I was, digging through that drawer, trying to work out when the water softener needed salt and how often a septic tank gets pumped. Did you know a tankless water heater needs flushing every year? I didn't. Most first-time owners don't. You find out when something breaks.

So: see a need, fill a need. Then my family wanted it too Around the same time, my brother-in-law pitched almost the same idea. He lives in a regular house in a regular neighborhood: no well, no septic, no propane. He still had the same problem. Filters, gutters, smoke detector batteries, the furnace guy's number: it all lives in scattered notes, old receipts, and memory.

That gave me my test. If one model handles a ranch and a suburban house, it's general enough for almost anyone. That includes condos, where the HOA owns the outside, and renters, where the landlord is just another contact. A week later, you can open it This moved faster than I expected. There's now a walkthrough of the whole thing at dwellogs.com/see, and none of it is a mock-up: every screen is the app.

Here's how it goes.

You start by pointing at your place. A house, a ranch, a farm, a cabin, a tiny house, a boat, or a patch of land with nothing on it yet. What you pick changes what you get asked later. A boat is never asked about a basement.

Then you fill in as much or as little as you like. There's no wizard. Every section is a tile you can open in any order, and "not set" is a state, not a failure. If you want to skip everything and go straight to the broken dryer, do that.

It asks what your place runs on. Well or city water, septic or sewer, wood, propane, or kerosene. One house often runs all three. Each answer brings its own check-ups with it. "Not sure yet" is a real answer, and nothing you haven't answered will ever chase you about it.

It knows where you are, roughly. The climate is guessed from your region and corrected by you. Where the house sits is a separate question. Two houses in the same county need different work if one is on a valley floor that frosts and the other is under trees that fill the gutters.

It keeps a list of what needs doing. Nobody sets up a home app mid-leak. You do it on a calm morning with three or four jobs already in your head. A job and a fault get filed separately, and "it works sometimes" is its own answer, because the thing that fails on Tuesday and behaves on Wednesday never quite earns the call.

Then it has a pulse. The line across the top is drawn from your own things: one shape per thing you track, with its height showing how close that thing is to needing you. A well gets a pump curve, a septic tank a square wave, and anything that burns gets a flame spike. Two places never draw the same line.

It only speaks when you ask. Reminders are off by default. Choose an email digest or a feed your calendar reads, and set a cap it won't go past. An empty digest is never sent.

And it isn't all in one person's head. Invite somebody and they get a link that carries everything. One tap and they're in, and they can see what's due and mark it done. Costs are off by default and on their own switch, because somebody helping with the list doesn't need to know what the roof quote came in at. What I've learned building it This is where the Salesforce brain kicked in. Some of these surprised me.

1. Not everything is "every N months." Every to-do app assumes a schedule is a calendar interval. That's true for air filters, but softener salt runs out at a rate: one bag every two weeks, and you want five on hand. Propane is neither. You check the level, and when it crosses a line, you order a fill. So DwelLogs has three kinds of schedules: time-based, consumption-based, and level-based. Squeezing salt and propane into "every N months" would mean the app lies to you.

2. Every interval says where it came from. This is my answer to the drawer. A check-up in DwelLogs tells you whether its timing comes from the manual, from code, or from our best estimate. You can trust it at the level it deserves, and change it when you know better.

3. Three fridges is an ordinary number of fridges. Salesforce folks will recognize this one. A fridge type carries the default check-ups, and each real fridge is its own record with its own filter part number. You enter counts, not checkboxes, because one row for all three would lose two of them.

4. Silence is a correct output. The easiest way to make an app nobody opens is to have it nag. DwelLogs doesn't remind you about something you haven't told it, and if you moved in during June, it won't ask about winterizing you can't judge yet. A calm pulse line is a true reading, not a reward.

5. Words matter. They're check-ups, not chores. Status is healthy, due soon, or needs attention, never "overdue" or "failed." There's no "honey-do." The app is for anyone who holds the keys, whether they live alone or share the house.

6. Draw the v1 line by building, not by arguing. I designed a lot of the data model up front: 36 tables, covering animals, warranties, budgets, emergency plans, and how buildings connect to each other. Then I built the first-run flow, from an empty screen to something worth opening tomorrow. That path touched nine tables. Add what makes it worth keeping past week one, and v1 is sixteen. The other twenty are real and designed, and they wait.

7. Your data should live where you can see it. Right now, DwelLogs saves to your device by default, and nothing leaves it. If you want it on a second device, or want to share it, your log lives in a Google Sheet you own, with a small Apps Script in front of it. There's no account. And if you ever want out, you already have the whole thing in a spreadsheet.

That setup is a test harness, built to put a real year of a real house through the model and find where it hurts. It will be replaced. But it taught me one Apps Script lesson worth passing on: if a static site calls your web app, deploy it as Execute as: Me. "User accessing the web app" sounds safer, but the browser gets a sign-in redirect instead of an answer, and fetch fails with what looks like a CORS error. It isn't one. Where it's at DwelLogs is an early test. The app is at dwellogs.com/app, and you can try it on your own device with nothing leaving it. Things will move, and I want to hear what breaks.

If you've ever googled "how often do you pump a septic tank" at 11pm, this one's for you.

See a need, fill a need.

13:29:15.191 (1878656913)|SOQL_EXECUTE_END|[358]|Rows:1
13:29:26.282 (12282920584)|DML_BEGIN|[357]|Op:Update|Type:SObject|Rows:4

Look at the clock. 15.191 and then 26.282.

Eleven seconds. Between two lines that sit right next to each other in the file.

Ten point four of those seconds are unaccounted for, and they are sixty percent of everything that transaction logged.

Nobody had ever looked at it. Not because anyone was careless — because there was nothing there to look at.

A quick note on which number to trust

Those two lines carry two different clocks, and they disagree.

The wall clock says 11.091 seconds. The nanosecond counter in brackets says 10.404. They are 687 milliseconds apart, in the same file, describing the same gap.

I use the nanosecond counter, because that is the one Salesforce actually measures elapsed time with; the wall clock is stamped per line and drifts. But the honest answer is that I picked one and told you which. Telling you which one I picked is the least I can do, and it runs through the rest of this.

The expensive part is often the gap

This is the thing I keep coming back to. A debug log is a list of things that happened. Every line is an event: a query ran, a method started, a DML statement fired. The tooling we all use reads that list and shows it to you, prettier.

But the expensive thing in a slow transaction is very often not an event. It's the absence of one. It's the time between two events that nothing accounts for.

And a list of events has no row for "and then eleven seconds passed."

So when you open a 25 MB log looking for what made your save slow, every tool you have — including the raw file, including the Developer Console, including the good open-source flame chart extensions — shows you the things that are there. The gap is rendered as exactly what it looks like: two adjacent lines. You scroll past it, because it's not shaped like a problem.

I scrolled past that particular gap for a long time.

I come in as the cleaner

I've been building on Salesforce since 2007. LogMeIn first, where I was one of the only people who touched the Apex, then Facebook, then a few years at Salesforce itself, and now managing a systems engineering team at SurveyMonkey.

Almost none of that has been the shiny new thing. I come in as the cleaner.

The org has been hoarded. The business kept adding and nobody ever prioritized removing, so there are hacks on hacks and code that should never have passed review — usually not because anyone was bad at their job, but because there was pressure to ship a thing, or because they genuinely didn't know better yet. Then those people moved on, or the company did, and what's left is mounds of automation nobody living can account for.

This is not a small-company problem either. Even at the mothership there were years of things that did a job once and were never turned off, layered into the clutter, on an org too heavily built on to migrate away from. Teams needed it. It didn't work well. Rebuilding cost more than enduring. So it stayed.

Change avoidance is real, everywhere, and it isn't stupid: the evil you know is safer than the evil you don't.

The consistent thing across all of it is not that the code is bad. It's that nobody can see what's actually in play any more. You can see the errors, sure. Errors are easy — something broke and said so. What I wanted was to watch a save happen and see the whole route: which trigger fired, what it called, which flow woke up, which workflow rule fired on the way past, what each of them touched. Not what the code says can happen. What did happen, this time, in order.

Because you cannot cut the fat if you can't see it. You end up guessing at what's safe to remove, which is how things never get removed.

And if you've done this work you know the feeling. Something is slow. You turn logging up to FINEST. You get back a 25 MB text file with 168,000 lines in it, and roughly 400 of them matter, and you have no idea which 400.

I got tired of that. So around ten years in, I started building something that wouldn't just tell me, but show me. I wanted to see it visually.

Four times

I've built this tool four times now.

The first was an Apps Script I wrote from scratch. It took months and it paid off — it did the thing I actually needed, which at the time was enough. I lost it. Not deprecated, not replaced: lost. It is simply gone, and everything since has been partly an attempt to get back to where it already was.

The second was Apex, in the org — a custom object, attach a log file to it, a trigger parses the body. I got the plumbing working and then life happened. That code still exists in a folder on my laptop, with the parser half-written and the next step commented out at the bottom.

The third was another Apps Script, about a year ago. It worked, in the sense that it produced output. It was also wrong in ways I didn't find until I went looking, which I'll come back to. It was a stepping stone, and I didn't know that at the time — you rarely do.

The fourth is the current one, and it exists because AI made another attempt survivable. Not because it wrote the code — because it made the tedious parts fast enough that I could keep my attention on the parts that actually needed thinking about. That's a real difference, and I don't think we talk about it honestly enough.

What the last one got wrong

Worth being specific here, because it's the whole reason I care about this so much.

My own tool — the one I wrote, the one I trusted — had a bug where it never handled FATAL_ERROR at all. One of my sample logs contained four of them. The actual reason that transaction died, System.LimitException: Apex CPU time limit exceeded, did not appear anywhere in the output. The tool read the log, produced a nice tidy report, and silently omitted the cause of death.

It got worse. It had a pattern for the marker Salesforce inserts when it discards part of a log, and the pattern was wrong — it looked for four asterisks where Salesforce writes three. So a log that was missing 35.8 MB of content came back reported as complete, with confident-looking timings computed from data that wasn't there.

That's the failure mode that scares me. Not a tool that breaks. A tool that's quietly, plausibly wrong, and hands you a number you'll repeat in a meeting.

So the current version has a rule: never invent a number. If a duration wasn't measured, don't display one. If Salesforce threw away part of the log, say so before saying anything else. If the same work ran twice and the clock disagrees, report the spread rather than the average and let the reader decide whether to trust it.

What it says now

Fed the same log, the current version opens with this:

10.40 s — 60% of the whole transaction — is unlogged time, between SOQL_EXECUTE_END and DML_BEGIN.

Overall, 96% of the elapsed time has no log line explaining it.

2 updates cost 5.13 s across 5 rows; the slowest single one took 4.63 s. That span includes every trigger, flow and validation the save set off — not just the write.

That last line matters more than it looks. A DML_BEGIN to DML_END span isn't the write. It's the write plus every trigger, flow, workflow and validation rule the write woke up. So "saving Accounts is slow" is almost never the finding. The finding is what the save set off.

Ninety-six percent unaccounted, incidentally, is not unusual. It's what a log looks like when most of the real cost is happening somewhere the log doesn't narrate.

And then it caught me

I wrote a draft of this post that said "that transaction took 17.3 seconds end to end."

It didn't. Or rather: I don't know that it did, and neither does the log.

A later version of the tool learned to check whether a log actually records the boundaries of its own transaction — the EXECUTION_STARTED and EXECUTION_FINISHED markers. This one records neither. It begins mid-transaction and stops before the end. So 17.3 seconds is the distance between the first and last lines that got written, which is not the same thing as how long the work took, and the difference is unknowable from this file.

I assumed that was a quirk of one unlucky log. Of the nineteen sitting on my machine, nine record both markers and ten record neither — including both of the largest, at 143,685 lines each.

Those nineteen are not a sample of anything, and I want to be careful about that, because it is exactly the kind of number this post is complaining about. They are the ones I pulled out of hundreds because they were slow, or enormous, or had already gone wrong. Nobody keeps the boring ones.

But that is also the only kind of log anybody opens on purpose. So the useful version of the finding is narrower and worse: among the logs you would actually bother to investigate, a good half cannot tell you where their own transaction started or stopped — and nothing on the face of one tells you which kind you're holding.

Run it through today and the tool says so itself:

The log does not record where this transaction ended. Neither the start nor the end of this transaction is recorded here, so 16.64 s of unlogged time and the span it is measured against describe the lines that were written, not necessarily the whole run.

I had written a post about tools that hand you confident numbers, using a confident number I had no business being confident about. The tool caught it. That is the most reassuring thing that has happened to this project.

The part that generalises

I don't think this is a Salesforce problem. I think it's a logging problem.

Almost every log format is a list of events, and almost every log tool is a better list. That's useful. But the interesting question is usually not "what happened" — it's "where did the time go," and those are different questions with different answers.

If you build or use log tooling of any kind, it's worth asking what yours does with silence. Does it show you a gap? Does it rank gaps? Does it tell you when it can't see the edges of what it's measuring? Or does it faithfully render two adjacent lines and leave you to notice the timestamps yourself?

Mine didn't, for years. Now it does, and it's the first thing it tells me.

It's free

The tool is called Saasy Logs. Paste a Salesforce Apex debug log into a Google Sheet and you get the route back: every trigger, flow, workflow rule, validation and class it hit, in the order it hit them, with a ranked diagnosis instead of a data dump.

It's free. Not free-for-now, not a trial, not a demo with the good part behind a wall — I built it because I needed it, and it costs me nothing to let you have it too.

It asks for no Google Drive permission at all. It can only see the spreadsheet you opened it from, there's no server behind it, and nothing is stored anywhere once the run finishes.

saasylogs.com

If you've got a log that breaks it, I'd honestly love to see it. That's how the last three bugs got found.

Winter '27 landed, and your daily driver got swapped out for the new Salesforce Web Console — a browser-native IDE built on the VS Code engine.

If there's one absolute constant in tech, it's change. Having spent more years in this ecosystem than I'd care to admit, I've learned that spending bandwidth complaining about lost muscle memory won't ship releases, and nostalgia won't pass a build. Pointing fingers and fighting the tide gets you nowhere. The quicker you pivot, adapt and master the new layout, the better.

So instead of grumbling, I went hunting that morning for my daily bread and butter: Apex code coverage.

Below are the eight steps to find it, with screenshots. Then, further down, what happened when I actually tried to live in this thing for a week.

First, why coverage even matters

This isn't about scraping past the arbitrary 75% threshold to force a deployment through a pipeline.

Too often, PRs include padded test classes that boost overall numbers without actually validating the lines of code being modified.

That's the part worth caring about. Coverage is only useful if it tells you what your functional tests are actually touching. A class sitting at 90% because someone wrote a test that instantiates it and asserts nothing is worse than a class at 60% where the covered lines are the ones that matter — because the first one lies to you and the second one doesn't.

So what I want from a console is line-by-line truth about which branches ran. Not a percentage.

Skip the fifteen-minute YouTube videos. Here's the straight version.

Step 1 — Enable coverage retrieval

Line-by-line coverage isn't calculated by default.

• Open Workspace Settings (Cmd + , or Ctrl + ,)

• Search for retrieve-test-code-coverage

• Check the box under Salesforce Apex Testing Configuration

Step 2 — Download target classes to your workspace

• Click the Org Browser (the cloud icon with refresh arrows) in the left Activity Bar

• Expand Apex Classes. This is a call to the org to retrieve the names in that folder, so give it a moment

• Find your target class and its test class

• Click the Cloud Download icon next to each to pull them into the browser workspace

Worth knowing now rather than later: expanding a folder and downloading a file are two separate trips to the org, and you repeat both for every metadata type you need. More on why that matters at the end.

Step 3 — Open the Apex Testing panel

• Click the Beaker icon in the left Activity Bar

• This pane lists every test suite and class loaded in your workspace

Step 4 — Run your tests

• Hover over the test class and click Play to run the whole suite, or expand the class to run individual methods

Step 5 — Watch the results

• Execution streams into the Test Results tab at the bottom

• Green checkmarks pass, red indicators are what you're about to go debug

Step 6 — Read the coverage summary

• The Output / Test Results panel gives you the overall Test Summary — org-wide coverage, duration, pass rate

• The Apex Code Coverage by Class table gives you per-class percentages and, usefully, the specific uncovered line numbers

Step 7 — Turn on editor highlighting

• Open the source file

• In the bottom-right status bar, click the Checklist icon (Highlight Apex Code)

Step 8 — Read the lines

This is the bit that actually earns its keep. Green is executed, red is not.

Look at what's red in that screenshot. It's a catch (Exception e) block. That's the shape of almost every coverage gap I've ever found: exception handlers, false branches, the path nobody thought about. A percentage would never have told me that. The highlighting does, instantly.

...When it works.

A week later, I went back to the old console

I said at the top that complaining about change gets you nowhere, and I meant it. So I gave it a real go — four days of actual work, not a tour.

By Friday I had reverted.

I want to be precise about why, because "I don't like it" isn't useful to anybody and it isn't what happened. Here's what happened:

You pay a round trip before you've opened anything. Expanding a metadata folder in the Org Browser — ApexClass, say — is a call out to the org just to fetch the names of what's in it. Only once that returns can you download the specific classes you actually want into the workspace. Then you do it again for the next folder: triggers, pages, whatever else the problem touches.

So the cost isn't "open a file." It's: wait for the console, wait for a folder listing, choose, download, repeat per folder. In a large org, fetching the names alone is not fast — and you're paying that before you know what you're looking for. Which, when you're debugging, is the entire situation you're in.

Multiply that by every org you touch. If you're jumping between a few orgs in a day, you would genuinely have to arrange your morning around it: open each one in advance and wait. That's not a workflow, that's a commute.

And it's every dev and full sandbox, because the change landed per org on September 1st — which is also where debugging actually happens.

Then the security improvements bite. You log in again. And again. And depending on where you land, you may get to re-download the classes you wanted to test against — the ones you already downloaded.

And the coverage itself was inconsistent. Following the exact steps above, line highlighting did not reliably show me covered lines. Sometimes it worked. Sometimes it didn't, with no obvious reason why.

Which is where I landed on the thing I actually want to say:

I shouldn't have to debug my debugger.

I'm not alone in this. Ignacio de Frutos Rosa said it under the original post before I'd written any of this down: "For serious development we already have VS Code. Developer Console was fine for quick log checks and execute anonymous in any org. The new console takes too long to set up for these quick things."

That's exactly it, and it's worth separating two different tools that got merged into one. If you're doing serious development you're in a desktop IDE already — you have been for years. The Developer Console was never competing with that. It was the thing you opened for ninety seconds to check a log or run an anonymous block in an org you don't otherwise live in. That job has a hard requirement: be fast to open. A browser IDE with a workspace, a download step and a re-auth is a fine tool for a job the Developer Console wasn't doing.

If you need to go back

Setup → Development → Web Console. Or just search console in Setup, which is faster. Then toggle the Enable Developer Console to: setting.

Two things about that.

You do it per org. Every developer and full sandbox that rolled over on September 1st needs the toggle flipped individually. There's no org-wide switch, so if you work across several, that's another small tax on top of the ones above.

Production hasn't been forced yet. At time of writing it still lists this as Web Console (Beta) and leaves the old console in place.

Which is worth sitting with for a second, because the rollout order is backwards for this particular tool. Production is where you're least likely to be poking at Apex all day. Sandboxes are where debugging actually happens — where you're jumping between orgs, checking a log, running an anonymous block, chasing something down. Salesforce forced the change exactly where the fast-open use case matters most, and left it optional where it barely matters at all.

I'd still say learn the new one. The legacy console is going away eventually, "eventually" always arrives, and doing it under deadline is worse than doing it now. Everything in the eight steps above works — I wrote them down precisely so the next person doesn't lose a morning to it.

But there's a difference between refusing to adapt and reporting a measurement. I adapted. Then I measured. The tool that's replacing the fast one isn't fast yet.

I'll try again at Spring '27.

Nineteen years of Salesforce, mostly spent reading debug logs. I also build Saasy Logs, a free Apex debug log analyzer, for exactly the reason you'd expect.

A version of this first appeared on LinkedIn.