# Gavin Vickery's Blog

## About the Author

I'm a dad to three daughters who keep me grounded (and entertained). When I'm not building software, you'll find me designing board games, making weird sounds with my eurorack synth collection, or diving into whatever new hobby has caught my attention that week. I'm endlessly curious and love learning new things—even when I'm terrible at them at first.

## Blog Posts

### So you're feeling the AI FOMO, huh? Let's fix that.

Published: February 5, 2026 | Reading Time: 8 min read

I get it. AI is... confusing... overwhelming? There's a new tool every week, a new headline every day, and it feels like everyone around you is somehow crushing it while you're still trying to figure out what the hell half of this stuff even does.

I guess i take this for granted. I use AI all day, every day. It's baked into how I write code, manage projects, organize my notes, prep for meetings. It's spilled into my personal life too. I built a spelling practice app for my kids in a couple hours. I released a [country album on Spotify](https://open.spotify.com/album/4bWa0UxtaPciVFhuoNhOiP?si=t4nyIjm8RvOufHlP3mXswQ) in 48 hours just to see if I could (I dont even like country!). This stuff is second nature to me at this point.

When friends or clients ask me how I do the things I do, and I start explaining, they glaze over. Every time. And I've realized the problem isn't them. It's me. I'm starting too high. I'm talking about agents and workflows and context windows when they just want to know how to stop dreading their inbox. It's so easy to assume everyone just "knows" this shit. 

So I thought, maybe I take a step back and figure out how I can help.

Because beyond the baby steps, you know, asking ChatGPT random questions, making another Ghibli photo of yourself for Facebook... what's the *actual* use case that's valuable? How does AI help you get real work done? How do you start feeling like you're winning, even just a little bit?

So that's what this post is about. No technical background needed. No 50-tool listicle. No "learn Python first" roadmap (thats a programming language btw, one of my favs). Just the practical stuff that actually matters when you're a busy professional who wants to use AI without making it a second job.

## Good news, you're not crazy, it IS overwhelming

So, here's what's been bugging me. AI moves fast. Genuinely, uncomfortably fast. Every week there's a new tool, a new person on LinkedIn telling you you'll be unemployable by Thursday if you don't adopt their framework. It's exhausting. And honestly a little demoralizing if you're just trying to keep up. I'm watching part of my industry get eaten alive.

[77% of workers](https://investors.upwork.com/news-releases/news-release-details/upwork-study-finds-employee-workloads-rising-despite-increased-c) who *do* use AI say it actually increases their workload. As in, its making things harder for them! Seventy seven percent?! Sheesh. They're spending hours rewriting AI-generated emails that sound like a corporate robot, fact-checking stuff they're not sure is real, copy-pasting between six tools that don't talk to each other. I'd be skeptical too. Is it lunch yet?

But that's not an AI problem. That's a "using AI wrong" problem. And it's fixable. That's the whole point, right?

## Lets chat about the big ass elephant in the room

Did you know that [57% of employees](https://azumo.com/artificial-intelligence/ai-insights/ai-in-workplace-statistics) who use AI at work hide it. More than half. Statistically that means you probably are too (don't worry I won't tell). People are sneaking around with ChatGPT like it's contraband. There's this weird feeling that using AI means you're not doing "real work." That you're cutting corners or something. You'll boss will fire you and hire AGENT1337 instead.

But nobody feels guilty about using spellcheck, right? How is that not the same thing? AI handles the mechanical stuff, the formatting, the first draft, the "how do I even phrase this" part so you can focus on the actual thinking. The judgment. The relationships. The stuff that actually neeeeeds a human.

The person who writes a great client email in 2 minutes with AI isn't less skilled than the person who agonized over it for 20 minutes. They just have more energy left for the next thing.

[69% of company leaders](https://www.gallup.com/workplace/701195/frequent-workplace-continued-rise.aspx) are already using AI. They're not hiding it. They're building it into their strategy. Meanwhile the people doing the actual work feel weird about it. That's kind of ridiculous when you think about it. Wait... do those stats even make sense next to each other? Fuck it...

## The boring stuff is where AI shines

I know, know.. this isn't the sexy take. But follow me for a sec. The use cases that actually save people time are incredibly mundane. And do you actually WANT to do mundane work?

**Email drafting.** This is the big one. [A third of people](https://www.grammarly.com/blog/company/workplace-productivity-and-ai/) specifically want AI for this, and I get it. You know those moments when you're staring at a blank email trying to find the right tone and 30 minutes just vanish? AI gets you a first draft in seconds. You tweak it, hit send, move on.

**Summarizing long documents or threads.** Someone sends you a 40-page report? Cool. AI reads it and gives you the highlights. You just saved an hour. Maybe two. TLDR plz thx.

**Meeting notes.** Instead of frantically typing while trying to also participate in the conversation, let AI handle the transcript. This one's almost too obvious. I use it all the time. Why are you taking notes when you should be listening!?

**First drafts of anything.** Reports, proposals, social posts, performance reviews. The blank page is the enemy. AI kills the blank page. I do this with my D&D sessions ha ha. Great way to kickstart the thought. It's like a cure to writers block.

**Brainstorming when you're stuck.** Kind of the same as the above, but worth re-framing. AI is a decent thinking partner. Not because it has brilliant ideas, but because it gives you something to react to. Sometimes you just need someone to throw stuff at the wall so you can say "not that, but close" and suddenly you know exactly what you want.

People who use AI for this kind of stuff [save around 3.5 hours a week](https://azumo.com/artificial-intelligence/ai-insights/ai-in-workplace-statistics) on average. That's not gonna change your life, but that's half a day back. I'll take that. And then we can build on it!

## One tool, one task. That's it.

The trick to getting this right when you're new is as follows...

**Pick one tool.** ChatGPT, Google Gemini or Claude (Don't pick ChatGPT). That's it. Don't install five things. Don't spend a weekend comparing features. Just pick one and go.

I use Claude every day, so I'm biased and yes, I know how that sounds. But honestly? For getting started it doesn't matter. They're all good, they both have free tiers. Pick whichever, move on. You can nerd out about the differences later.

**Pick one task you already do.** Not something new and exciting. Something you do every day that's kind of a pain. Writing emails, prepping for a meeting, summarizing your notes after a call, drafting a report you've been putting off. Something boring. Something you'll do again tomorrow.

The goal here isn't to revolutionize anything. It's to see AI handle something familiar, go "huh, that was actually pretty good," and build from there.

**Learn one prompting trick.** This is the part most people skip, and it's why their results suck. Talking to AI isn't like Googling. You can't just type "email" and expect magic. You gotta give it context.

Here's what's been working for me:

- **Role:** "Act as a [senior marketing manager / executive assistant / whatever fits]"
- **Task:** "I need you to [draft an email / summarize this / brainstorm ideas for X]"
- **Context:** "Here's the background: [paste the relevant details]"
- **Format:** "Give me this as [bullet points / a short email / a table]"

That's it. Role, task, context, format. Takes 30 seconds to learn. Make a template if you want. Or better yet, get the AI to help you make a template to help the AI. Ok, now you're getting it!

Here's what this looks like in practice. Instead of:

> "Write me an email about the project update"

You type:

> "Act as a project manager. I need to send a status update to my team about the website redesign. We're two days ahead of schedule, the design phase is complete, and development starts Monday. The client is happy with the mockups. Give me a short, upbeat email no more than 150 words. And don't make me sound like a corporate douche."

Ok wait... the difference in output actually blew my mind the first time I tried this. It went from generic slop to something I'd almost send as-is. Especially that last part.

## A few things to know going in

I'm not gonna sit here and tell you AI is perfect. It's not. I use it every day and it still annoys the hell out of me sometimes. When you use it this much, you really start to find its edges.

**It makes stuff up.** This is real and it's prob the biggest gotcha. AI will confidently tell you something that's completely wrong. I've seen it happen with code, with facts, with dates. You cannot just copy-paste AI output and call it done. Use it for the first draft, then review it with your own brain. If you wouldn't send an email a junior employee wrote without reading it first, don't do it with AI either.

**Privacy matters.** Don't paste confidential data, trade secrets, or sensitive customer info into free AI tools. Just don't. Enterprise versions like ChatGPT Enterprise and Claude for Business have proper data protection baked in. If your company has an AI policy, follow it. If they don't... maybe be the person who suggests they create one. Good look for you honestly.

**It sounds robotic at first.** Everyone's initial reaction is "this sounds nothing like me." The fix is stupid simple: just tell it how you want it to sound. "Write this like a human, casual tone, no corporate speak." Or paste something you've written and say "match this style." It adapts fast. It's prob just me (it usually is), but I think most people give up before they figure this part out.

**Ugh, I'm tired of seeing AI influencer stuff.** The people posting "I built a $10K business with AI in a weekend" are either lying, leaving out massive context, or are technical people who already knew how to build things. Ignore them. Your goal is way simpler. save time on stuff you already do.

## Alright, I'm done holding your hand

Here's your homework. 15 minutes. That's it.

1. Go to [chat.openai.com](https://chat.openai.com) or [claude.ai](https://claude.ai) and create a free account
2. Think of something you need to write today, that could be an email, a summary, a message, anything
3. Use the Role + Task + Context + Format thing and ask AI to draft it
4. Edit it so it sounds like you
5. Send it
6. Grab a beer

That's it. You just used AI at work. World didn't end. And it probably took half the time. Or maybe it took more. But the important thing is you're getting the flow. Next time it'll take a little less, then a little less.

Do it again tomorrow. And the day after. Within a week you'll start developing instincts for what AI handles well and what it's useless for. You'll get faster at prompting. You'll wonder why you waited this long.

[Nearly half of all employees](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/superagency-in-the-workplace-empowering-people-to-unlock-ais-full-potential-at-work) say they want AI training but their companies aren't providing it. Which sucks. But you don't need a corporate training program to get started. You need 15 minutes and the willingness to feel a little awkward trying something new.

Install it on your phone if you have too. Message Claude while you're on the throne. God knows everyone else does.

## Need to level up?

If you try this stuff and think "ok, what else can it do?", well there's a lot more. Custom instructions that make AI match your voice automatically. Workflows that chain tools together. AI agents that buy your groceries and order them to your house (yes I do that). Ways to use AI that go way beyond chatting in a browser window. It gets really fun once you get past the basics. I'm excited. Are you excited!? YOU SHOULD BE EXCITED!

I help people and teams figure this stuff out. Not theoretical frameworks, actual "here's how this applies to your specific job" kind of stuff. If you gave the 15 minutes a shot, [tell me how it went](https://www.linkedin.com/in/geekforbrains/). Seriously, I wanna hear what you tried first. Message me and we'll hop on a call and we can nerd out about who rad this stuff is.

Ok bye. Call me.

---

### My AI assistant woke me up at 3am

Published: January 30, 2026 | Reading Time: 6 min read

![Cat Agents](../../assets/images/cat_agents.png)

At 3am, my phone buzzed. It was my AI assistant. Uhhh, what? I rolled over and blinked at my phone. It was asking for a two-factor authentication code...

I typed it in half-asleep, went back to bed, and thought: did that actually work?

When I woke up, it had finished. The assistant had created its own developer account under our company, set up an OAuth app, grabbed API keys, gone through the browser auth flow, written the integration code, and validated it. I'd asked it to connect some reporting software before bed. I didn't expect it to actually do it. Holy shit!

That was the moment it stopped feeling like a chatbot and my work on it had paid off.

## The spark

When OpenClaw (aka: Clawdbot / Moltbot) went viral, I was already tinkering with this stuff. But seeing that project blow up gave me new energy. It proved the concept - an AI agent that connects to messaging apps and actually does things on your computer.

But OpenClaw felt heavy to me. And wildly insecure. I wanted something leaner. Minimal. So I set out to build my own. Big surprise ha ha. 

## The mental model that changed everything

I started thinking about it like hiring a real employee.

A real assistant needs hardware. An email address. Accounts. So I gave it those things. Its own MacBook, Apple ID and a real company email.

This framing drove real decisions and helped me change my goals and perspective a bit. The assistant doesn't just run code - it can physically control a computer. Open a browser, click around, fill out forms. When code can't solve a problem, it can do what a human would do. Google it, figure it out and navigate the UI. It's also insanely fun to just watch. 

That's how it handled the integration. It got stuck at one point, so it opened a browser and worked through the OAuth flow manually. Just like a person would. This felt like an unlock moment.

## The hard problem isn't what's done - it's what's in the air

Tracking completed tasks is easy. A database with status flags. Done. Thats what basic bots do.

I think the tricky part is tracking what I call "threads" - the balls in the air. Things that aren't tasks, they're ongoing situations. An email I saw but haven't responded to. Waiting on someone to get back to me. Something I need to follow up on in a day or two if I don't hear back. They're kind of tasks, but kind of not. 

Here's a recent example. I run a coworking space, and a member emailed saying they wanted to renew. The assistant received the email, looked up their Stripe account, noticed they were on manual invoicing instead of a subscription, and emailed them asking which they'd prefer going forward.

Then it waited. Tracked the thread. Eventually the member replied. The assistant texted me for confirmation before taking action. I said "go ahead." It set up the subscription, notified the member, and closed the thread.

My total involvement was **one text message**.

Ok, now we're getting somewhere...

## The efficiency trick

I didn't want to burn tokens polling every minute. I actually did initially, and Claude Code was pissed. "Hey, do I have any new emails?" over and over gets expensive fast.

So there's code that acts as a gatekeeper. It loops regularly, checks the inbox against a database of emails the agent has already seen. Only when something new appears does it wake up the AI - and only passes the new stuff, not everything.

Same for threads. They have statuses and timeouts. Code monitors the table, notices when a deadline passes or a related email arrives. Even notices when I don't respond for a few hours and gently follows up with me. The code handles "when." The AI handles "what." You only pay for intelligence when there's actually a decision to make.

## The trust ladder

An assistant is only useful if it can act autonomously. But you can't trust a new assistant with everything on day one. So there's graduated autonomy. It asks before anything irreversible. Sends me a confirmation before setting up that subscription. Checks before sending an email on my behalf. This mirrors how you'd train a human assistant. They don't start with access to your bank accounts.

Over time, trust builds. The assistant earns more autonomy through consistent good judgment. Just like a real employee would. 

At this point, my wife starts noting I'm talking to my AI assistant more than her. Oh boy... 😅

## The cat

One last thing. We started with an AI-generated photo of a person as the avatar. Realistic looking. That was on me.

**The team hated it.**

It was too human. Kinda off-putting I guess? People kept commenting on how weird it felt to interact with something that looked like a real person but wasn't.

Anyway, we switched to a cat character. This felt a little more playful, clearly not human, but still approachable. Win!

## What I learned so far

The gap between a chatbot and an assistant isn't intelligence - it's agency. The ability to track things over time, make judgment calls, act on your behalf, and know when to escalate. That concept of threads and trust.

Most AI assistants are reactive. You ask, they answer. Maybe they trigger some automations. Pfft, thats so early 2025.

A real assistant initiates. Follows up and remembers that you're waiting on someone. Nudges you when you've let something slip (which is a lot hah).

The technology to build this exists. The hard part is the design - figuring out when to involve the AI, how to maintain context across interactions, how much autonomy to grant.

I'm still iterating. But waking up to a completed integration I didn't think would work? That felt like a glimpse of something new.

---

### What the hell is a fractional CTO?

Published: January 26, 2026 | Reading Time: 8 min read

![Fractional CTO](../../assets/images/fractional_cto.png)

I recently wrote about [where my agency fits now](https://geekforbrains.com/blog/where-does-my-agency-fit-now/) that the industry is shifting under our feet. The $20-50k MVP is dead. AI tools build prototypes for free. So what do I do with 20 years of experience when the barrier to entry just dropped to zero?

One answer keeps coming up in conversations with founders in my network. They'll say something like, "Have you thought about doing fractional work?".

Honestly? I hadn't, not seriously anyway. I know what a CTO does, I am one! But "fractional"? What does that even mean in practice? It sounds like you're giving someone a fraction of leadership. Less than the whole thing. Thats probably what it is, but is that even useful?

So I did what I always do when something bugs me. I spent an ungodly amount of time reading and poking at ideas.

## So what does "fractional" even mean?

A fractional CTO is exactly what it sounds like. A Chief Technology Officer who works part-time across multiple companies instead of full-time at one. But there's some nuances here.

The "fraction" isn't about quality, but rather time. You're not getting less value, you're getting focused value. Instead of 40+ hours at a single company, you might spend 10-20 hours per week with a client. One or two days. Focused on the strategic shit, not day-to-day firefighting. Ok, I'm officially intrigued. It sounds like all the fun stuff and less of the boring day-to-day.

It's different from consulting, which tends to be project-based with defined deliverables, closer to the agency I run now. A fractional CTO embeds more deeply. They join leadership meetings, mentor the team, etc. They stick around for months or years, not just until a project wraps. It's also different from an "interim CTO", who's basically a full-time temporary replacement while you search for a permanent hire. Fractional is part-time and ongoing.

## But, who actually needs this?

Ok, the picture was starting to take shape. But part of me still didn't quite "get it". There wasn't a clear persona I could imagine that needed this. Turns out there are three pretty distinct markets, and they need different things.

#### Startups

The obvious one, and a space I've spent a lot of time in. This fractional model has become [the default for Series A and bootstrapped SaaS companies](https://newsletter.pragmaticengineer.com/p/fractional-cto). Companies that need real technology leadership but can't justify a $200k+ exec salary plus equity plus benefits, yada yada yada. 

I don't think this is pre-seed or idea-stage startups though. The advice there is "save your money" and find a technical co-founder instead. Good advice IMO. The sweet spot is scale-ups. Companies that have launched something, are growing, but haven't outgrown the need for outside help.

#### Small and medium businesses

At first, this angle surprised me. I've mainly focused on the tech sector, not brick and mortar. These are established businesses, been around for years, maybe decades, that are hitting technology walls or feel the pressure to innovate on new tools (but don't know how to).

The problems are different of course. It's not "build from scratch." It's modernization. Legacy systems. Digital transformation. [65% of businesses start modernization projects](https://www.galloptechgroup.com/blog/impact-of-fractional-cto-on-business/), but only 10% complete them. That's a lot of stalled initiatives. But also sounds painfully similar to unfocused feature development that startups find themselves in. SMBs also deal with compliance headaches, vendor management, and mentoring existing staff rather than hiring new ones. They need someone who can work with what's already there, not start fresh. Makes sense really.

And this segment is [growing fastest](https://columncontent.com/fractional-work-statistics/), it was projected to hit 35% adoption in 2025. By 2027, [over 30% of midsize enterprises](https://thectoclub.com/career/fractional-cto/) are expected to have at least one fractional executive on retainer. Wow, how have I been sleeping on this?!

#### Enterprise and private equity

You'd think big companies already have CTOs. Well, they do. And probably wear nice suits and shit like that. But there's a specific use case I hadn't considered. PE portfolio companies.

When a private equity firm acquires a company, they often bring in a fractional CTO for due diligence, post-acquisition cleanup, or exit preparation. [Tech companies with well-managed systems exit at 6.2x revenue versus 4.1x for those with technical debt](https://deconstrainers.com/articles/fractional-cto-guide/). On a $50M acquisition, that's $10-15M in lost value. Think of all those fancy executive suits they could have bought!

But this is very specialized work. Bounded timeframes, high stakes, specific deliverables. Not ongoing advisory, more like "fix this before we sell." Still a decent market though.

## Wait. I think I already do this.

While working on this post, I had a moment of realization. 

A friend of mine owns a steel detailing and drafting company. About 25 people. For years I've helped him manage his tech stack, set up backup systems, handle server infrastructure, onboard new team members onto their tools. He's big enough to have real technical challenges but nowhere near big enough to need a dedicated CTO. Normally he just buys me lunch (which I greatly appreciate, Lee!). 

Another friend runs a dental practice, actually multiple dentists sharing a larger practice. I've helped them evaluate new tools, consider how to train staff on technology, find ways to lower their software licensing overhead. Nothing glamorous, but real problems that needed someone technical to think through.

There are a couple more examples like this. Friends who own businesses, needed technical help, and I just... helped. Because that's what you do and grab a beer.

I never thought of it as "fractional CTO work." I thought of it as helping friends. But reading through all this research, that's exactly what it is. Strategic technology guidance for businesses that need it but don't need someone full-time.

The only difference is I've been doing it for free.

## What do they actually do?

Now that I'm looking at my own experience through this lens, the breakdown makes a little more sense.

- **60%+ strategic work** - Technology roadmaps, architecture decisions, vendor selection, aligning tech with business goals
- **Team development** - Mentoring staff, helping with hiring, building processes
- **Light operational** - Maybe 15% firefighting, security oversight, keeping things running

The key difference from a full-time CTO is focus. You're not attending every meeting or getting pulled into every minor issue. You're there for the decisions that shape the next 6-12 months, not the ones that shape the next sprint.

Most engagements run 10-15 hours per month. Some fractional CTOs support 4-5 clients simultaneously. That personally sounds like too many. I bet 3 is the sweet spot. Either way, the model works because each company doesn't need 40 hours of CTO attention every week. They need the right 10 hours.

## The honest tradeoffs

This all sounds great. But what are the downsides? You can't have your cake and eat it too, right?

**Divided attention** is real. If you're juggling multiple clients and one has a major outage, you might be in a meeting with another. That's uncomfortable for everyone. How is this managed with verbal expectations as well as contract? 

**Shallow context** is a risk. Part-time means you'll never know the systems as well as someone who lives in them. You might miss dynamics that affect technical decisions. I talked about this in my previous post, but digging in is something I love. Part of the craft. Do I always want to be high level? 

**Limited influence** could suck. Full-time executives can push through organizational change over months. Fractional leaders often can't. Your time is limited, so your ability to effect deep cultural shifts is too. I'd hate to put in all that time and see them go down a totally different path. 

I guess none of these are dealbreakers, but they're still worth considering. The model works best when a company needs strategic guidance, not day-to-day operational leadership.

## So where would I actually fit?

This is the question I keep circling back to.

**Startups** are the default market, but I'm not sure that's where I want to be. It's crowded. And honestly, I've done the "build from zero" thing enough times. The chaos of early-stage startups is fun when you're 25. At this point I've seen enough seed-stage companies implode that I'm a little tired of it. Maybe I'm just getting old...

**SMBs in growth mode** feel more interesting to me. Established businesses hitting technology walls. Companies with real revenue, real teams, real problems. But no dedicated technical leadership. That's the work I've apparently already been doing for friends. Modernization, mentoring, making existing systems work better. 

**PE portfolio work** is intriguing but specialized. High stakes, bounded engagements, specific outcomes. I've done some enterprise work before, but always embedded with internal teams on specific initiatives. The PE angle is different, more like consulting with teeth. Worth exploring, but my spidey-senses tell me I prob won't dig it. 

## Why I'm even thinking about this

Here's where this connects to my [earlier post about my agency](https://geekforbrains.com/blog/where-does-my-agency-fit-now/).

I listed a bunch of possible pivots. Scale-up specialists. Distribution partners. Vibe-coding accelerators. Vertical specialists. But one option I didn't really explore... what if the value isn't in building things anymore, but in knowing what to build?

I've spent 15 years making technology decisions at the executive level. Architecture, team building, scaling, technical debt. I've seen what works and what breaks. I've made expensive mistakes and learned from them.

When founders ask me questions now, they're not usually asking "can you build this for me?" They're asking "should I build this at all?" and "how do I think about scaling?" and "what's going to bite me in six months?"

That's not development work. That's CTO work. And maybe I've been giving it away for free in conversations when I could be packaging it as a service. That feels cringy to even say. I hate feeling like a sales person. But a guys gotta eat too (thats a bit dramatic, you get what I mean).

## The part I'm still wrestling with

There's something that feels strange about not being all-in somewhere. About being the person who shows up two days a week and leaves before the hard parts. Even if that's not actually how it works, that's the feeling I'm wrestling with. Maybe that's just ego. Maybe "all-in" is the wrong frame for certain kinds of help. A surgeon isn't less valuable because they don't live at the hospital. But I've always been the guy in the trenches. Writing code. Shipping product. Sitting with the team at 2am when things are on fire. Going fractional feels like stepping back from that. I'm not sure if that's growth or retreat.

## What I'm still figuring out

A few questions I don't have answers to yet:

- Is the value in the hours, or in having someone experienced available when decisions need to be made? Do I want to be "on call"?
- How do you build real trust with a team when you're only there part-time? I feel like resistance from non-exec staff will be strong. How do you handle that?
- Do I focus on one segment or try to serve multiple? The answer is usually focus. But is there enough market?
- Is this a transition to something else, or a destination and where does this sit with my agency? Are they hiring me personally, or do I position my team as Fractional CTO's collectively? 

I discovered that [72.8% of fractional tech leaders](https://columncontent.com/fractional-work-statistics/) have 15+ years of experience. That tracks. You're not hiring someone junior for this. You're paying for pattern recognition. For someone who's seen the problem before and knows how to talk to the other humans.

I've got the experience. I've apparently already been doing the work. The question is whether I formalize it, and whether that's interesting to anyone besides my friends.

I'm sharing this because I suspect I'm not the only experienced tech leader asking these questions. If you've gone down this path, or you've hired a fractional CTO, I'd genuinely love to hear what you learned.

For now, I'm still figuring it out while I try to keep shiny side up 😅

---

### Where does my agency fit now?

Published: January 23, 2026 | Reading Time: 8 min read

![Gavin Vickery](../../assets/images/gavin_vickery_questions.jpg)

I run a software development company. For years, clients came to us with requests like, "Can you build my MVP?" They'd have an idea, need validation, and we'd charge $20-50k to build a prototype. Most failed. That was just the reality of startups.

By mid-2025, those requests stopped. Completely. And I was freaking out.

I think the requests stopped, not because people stopped having ideas, but because tools like Lovable, Bolt, and Replit can now build that same MVP in a weekend for free. Anyone can vibe-code a basic app without writing a single line of code.

I lied to myself, saying this was fine. They'd validate with AI tools, hit limitations, then come to us for "the real thing." Some did. Our remaining clients were better educated, post-validation, ready to invest properly.

But then I started seeing the numbers shift, and that shit was scary.

A flight simulator built in 3 hours making $87K per month. Solo founders hitting $100K MRR with vibe-coded products. A non-coder building a six-figure business on Replit in days. Apparently [25% of Y Combinator's Winter 2025 batch](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/) is running on 95% AI-generated code.

These are no longer validation projects. They're businesses. Stay calm Gavin... breath.

So I started asking a harder question, and probably the one many in my industry are asking too: 

**Where does my agency fit in this world? Or does it?**

## The validation revolution is genuinely empowering

From my perspective, here's what happened. The barrier to testing a product idea dropped from $50,000 to $0. That's true, because I've seen it first hand in my business with real clients.

You see examples of this all over now. Someone built a "Has the dog been fed?" tracker using Replit. It's perfect for them. Market of one. When the build cost approaches zero, you can build for an audience of yourself. This is honestly kinda cool. 

I've done this too. I built a spelling practice app for my kids in a couple hours. It scans their spelling sheet, reads words aloud, and lets them drill until they've got it. No searching for apps that almost work, no subscription fees, just exactly what we needed.

A friend built a hockey announcement app for his kids' team using Base44. It generates audio for player names, handles goal announcements, team lineups, the whole production. A fun, specific use case for his family that no commercial product would ever serve.

When the build cost approaches zero, you can build for an audience of one.

Tools like Lovable and Bolt build about 70-80% of any basic app in hours. For validation, that's perfect. Get user feedback quickly, prove the concept and learn what people actually want.

Most of these ideas will fail, and that's fine. Bad ideas should fail fast. Better to learn in a weekend than after months of development and tens of thousands of dollars.

## The uncomfortable evidence

[Pieter Levels built Fly.pieter.com](https://x.com/levelsio/status/1899596115210891751), a browser-based multiplayer flight simulator in 3 hours using Cursor. Within 17 days it hit $87K MRR. Now it has 320,000 users. He hasn't rebuilt it. It's still running on that original vanilla HTML/JavaScript. To be fair, Pieter has a huge network to sell too. But lets focus on the technical side here. 

[TrendFeed](https://www.indiehackers.com/post/tech/building-a-product-with-ai-in-four-days-and-hitting-12k-in-four-weeks-HxoUuTymcPNvhCNe8b6A) was built in 4 days with AI. Hit $12K revenue in 4 weeks. Now at $10K MRR. Sheesh.

[Chatbase](https://supabase.com/customers/chatbase) was built by a college student in 2 weeks using Supabase. He reached $8M ARR completely bootstrapped. Now its a polished, full-blown product with great branding.

A [Brazilian edtech used Lovable](https://analyticsindiamag.com/ai-news-updates/a-vibe-coded-app-made-3-million-in-48-hours-says-lovable-ceo/) to build a premium platform in 2 weeks. Generated $3M in revenue in 48 hours. $3M!? 48 hours. Thats unfair.

It's painful to admit, but these aren't outliers anymore. They're a pattern, and the pattern contradicts the story I was telling myself.

## The story I was telling myself

The story in my head went a little like this: vibe-coding for validation, professionals for "real" businesses. It felt true because it protected my business model. Go and have fun with your app idea. Call the big guns when you want something legit. Right? Riiiight!?

But look at the data:
- 83% of small businesses earn less than $100K annually
- Only 0.4% of SaaS startups reach $10M revenue
- 91% never hit $1M

Most businesses don't need enterprise-grade infrastructure. They don't need to scale to millions of users. They don't need the last 20% that professionals provide.

I would often say "plan to rebuild," but Steve Blank would call that "startup suicide." His argument is that while engineers rewrite, competitors add features and gain market share. You don't get to declare a timeout because your code is ugly. But being a software engineer who loves to code makes this painful.  It's part of the craft.

Airbnb started with founders manually taking photos of apartments. None of it was scaled. They iterated from there, they didn't wait for professionals to build it "properly." 

## Where my framework still holds

I don't think everything I believed was wrong. Some of it holds up.

The Airbnb example still matters, not for early-stage startups, but for what a business becomes. Yes, you *could* build something that looks like Airbnb's app using Bolt. But that app would have zero value. Because the app is maybe 10% of what makes Airbnb valuable.

The other 90% of Airbnb is trust systems, payment infrastructure, matching algorithms, fraud detection, multi-currency compliance, insurance frameworks, customer support at scale, network effects, brand reputation.

Same with Starbucks. Their app is the front-end to a closed-loop payment system. 17 million users locked into their ecosystem. Proprietary AI yielding 30% ROI boosts.

At this scale, the moat isn't the app. It's the ecosystem.

But lets look back at those earlier stats a second before we start lying to ourselves again. Most businesses aren't trying to become Airbnb or Starbucks. And for them, the vibe-coded version might be enough. $8M ARR as a solo founder? Yea, I'll take that.

## What's actually commoditized

Let me be honest about what died from our business.

Basic CRUD apps. Shit like ToDo lists, Landing pages, Marketing sites. Standard authentication systems. Generic productivity tools. The $20-50k MVP.

AI wrappers are another. I said they were dying. But [Cursor hit $500M ARR](https://techcrunch.com/2025/06/05/cursors-anysphere-nabs-9-9b-valuation-soars-past-500m-arr/) with zero marketing spend. [Harvey AI reached $100M ARR](https://www.cnbc.com/2025/08/04/legal-ai-startup-harvey-revenue.html) serving law firms. [PDF.ai](https://www.starterstory.com/pdf-ai-breakdown) makes $6M ARR as a solo founder project. These are "thin wrappers" that won through distribution, not technical moats.

The moat was never the code. It was distribution, network effects, timing, and brand. My inner engineer was dying inside. 

## The gap keeps shrinking

The 80/20 gap isn't stable anymore.

In August 2024, the [best AI solved 33% of SWE-bench](https://openai.com/index/introducing-swe-bench-verified/) coding challenges. By late 2025, [Claude Opus 4.5 solves 81%](https://www.anthropic.com/news/claude-opus-4-5). Context windows now ingest entire codebases. Autonomous agents take high-level plans and produce complete programs while you sleep.

What required professionals last year doesn't this year. That trend continues at an alarming rate. 

When I say "the last 20% requires professionals," I might be describing a temporary limitation, not a permanent truth. The AI army marches ever forward. 

## Where does my agency fit now?

This is where I stop having confident answers and start having questions.

Here are my thoughts around that, in no particular order:

**Scale-up specialists.** Only take clients who've hit real walls that iteration can't solve. Post-PMF, proven revenue, actual infrastructure problems. We're not building MVPs anymore, we're solving problems that emerge at scale. Higher bar, fewer clients, bigger budgets. This is closer to "devops engineer". This market is smaller. And AI might solve scale problems too.

**Distribution partners.** When technical barriers are low, distribution beats product. What if we pivoted from "we build your product" to "we get your product in front of users"? Growth engineering, not software engineering. We already do this, but maybe we put our foot on the gas? Do we want to be competing with dedicated marketing agencies.

**Vibe-coding accelerators.** Instead of building for clients, teach them to build themselves. Charge for strategy. Show them what to build, which problems matter, how to sequence features. The building becomes their job, we're the guide. 

**Vertical specialists.** Go deep in regulated verticals where compliance is the moat. Focus on areas we know well like healthcare, finance, legal. HIPAA, SOC2, FDA approval. These don't get vibe-coded away easily. There's hoops to jump through and getting it wrong is catastrophic. 

**AI-augmented boutique.** Embrace the tools fully. Smaller team, faster delivery, lower prices, higher volume. If vibe-coding does 80%, our value is the 20% plus quality control plus accountability. 

I don't know which of these is right. I'm probably going to try several. 

## What I'm watching

**The 80/20 line.** Every quarter the tools get better. If the gap closes faster than I expect, options 1 and 5 become less viable. If it stabilizes, they might be the play.

**Distribution as moat.** Calendly is a $3B company solving a trivially simple problem. Every Calendly link is an unpaid ad. Pieter Levels' $138K/month comes partly from 600K Twitter followers. If distribution is the real moat, maybe we should be building audiences, not apps.

**The rebuild rate.** How many vibe-coded businesses actually hit walls that force rebuilds? If most iterate successfully on their original base, the "plan to rebuild" advice is wrong. If most hit breaking points, we're the ones they call.

**Solo founder success stories.** Realistic solo founder timelines seem to cluster around $500-$2K month one, $5K-$25K by month six, $10K-$50K by month twelve. If those numbers hold, the "market of one" expands into "business of one." That's a different competitive landscape.

## What remains defensible

There's a few areas that still feel durable and are worth noting.

**Regulated moats.** Healthcare ($187B by 2030), banking licenses, FDA approval. Compliance complexity is a feature, not a bug. This might be the last safe harbor. It's also a pain in the ass.

**Network effects.** Not all networks are equal. Uber's proved weak, Airbnb's proved strong. But when they work, they're still defensible.

**Deep vertical integration.** Embedding into workflows creates switching costs. Implementation complexity creates barriers. This is where "the other 20%" still matters.

**Brand.** When product is commoditized, brand becomes differentiation. Generic AI apps are forgettable. But brand isn't something you hire an agency to build, it's something you earn over time.

## My honest conclusion

I started writing this post to explain why companies still need professional software development. I was going to tell you that vibe-coding is for validation, and real businesses hire people like us. Fat chance.

The evidence didn't support that clean story, as much as I tried to read around the facts. 

Some vibe-coded apps become real businesses. Most businesses don't need enterprise scale. The technical gap keeps shrinking. Distribution matters more than code quality. Professional development has its own problems like cost overruns, delays, technical debt.

So as of today, here's where I sit:

The $20-50k MVP is dead, and it's not coming back. Good riddance, it was a bad deal for founders anyway and boring to work on.

Some percentage of businesses that would have hired us will now succeed without us. That's fine and they should! Being a founder, I love seeing others win. Its infectious.

There's still a market for what we do. I'm just not sure how big it is, or how long it lasts, or what shape it takes. That ball is still very much in the air.

I'm not writing this post to pitch my services. I'm writing it because I think a lot of people in my industry are telling themselves comforting stories. I was too.

The barrier to entry dropped to zero.

The barrier to building something that matters? I used to think that stayed exactly where it was.

Now I'm not so sure. But I'm also too fucking stubborn to throw my hands in the air. So lets see how deep this rabbit hole goes. ✌🏻

---

### Claude Code meets Obsidian

Published: January 22, 2026 | Reading Time: 5 min read

![Obsidian](../../assets/images/obsidian.png)

For the last few weeks, I've been running Claude Code directly in my Obsidian vault full-time. Not through a plugin, I'm just running `claude` in the terminal, pointed at my notes folder.

I'm good at capturing information, terrible at maintaining it. Project notes, research, receipts, random measurements, it all goes into the vault and slowly becomes useless. Inconsistent formatting, no clear home. I knew I'd written something down but actually finding it when I needed it? Good luck.

Last year we built a fence. I had notes on measurements, materials, photos of receipts, permit details. All captured, all scattered. When my neighbor needed the breakdown to split costs it took me hours to piece together. I made mistakes, they caught them. Embarrassing, and exactly the kind of thing a "second brain" is supposed to prevent.

With this system that fence situation is maybe five minutes.

The combination works because Obsidian is just markdown files. No proprietary format, no database to query. Claude reads and writes the same files I do which means my meeting notes, project docs, code snippets, D&D campaign notes, everything becomes context Claude can work with.

This isn't AI writing for me. It's AI working alongside me, with access to my actual second brain. It's blending the fun parts of creativity and human thought with the monotony of process that computers are so good at.

## Why this matters

Your typical LLM chat interfaces are ephemeral. You explain context, get a response, close the tab. Next session, you start over. Some have memory, but honestly it's pretty shitty.

Claude Code + Obsidian flips this. My vault becomes persistent memory, it's at the front. The `CLAUDE.md` file in my notes folder contains instructions Claude reads every session and gets a lay of the land so I don't have to educate it each time. Define a workflow once, it applies forever.

To me though, the real power isn't in Claude remembering instructions. It's in Claude having access to everything I've captured, regardless of how half-assed it is. Meeting notes from recent client calls, project requirements I drafted months ago, research I've accumulated on various topics or interests, code scripts and technical documentation, character sheets, NPC backstories and world-building for my D&D campaigns.

When I ask Claude to help with something, it already knows where everything is and does the thing. I can crack my knuckles and grab a beer (well actually its tea, I'm doing Dry January...)

## What I've built

I've extended Claude Code with custom agents and skills that make this workflow practical.

Research agents let me browse the web, gather information, and save findings directly to my Obsidian notes. Instead of relying only on Claude's built-in tools, research that would take me hours of tab-switching happens in the background.

The /format command reformats notes to match my vault's style guidelines. Headers, lists, links, Claude applies consistent structure across whatever notes I throw at it.

The /sort command processes my inbox folder, figures out where notes belong based on content and my folder structure, adds appropriate tags, and moves them to their proper locations.

These commands solve a problem I've had for years. I'm great at capturing information, terrible at organizing it. Claude handles the maintenance work I always avoided.

## Nerding out with D&D

This is where the collaboration aspect really shines.

Running D&D campaigns means generating a lot of interconnected content. NPCs, locations, plot threads, item descriptions, session notes. Obsidian's linking makes these connections visible. Claude's access to the vault makes them actionable.

When I'm prepping a session, I can riff ideas with Claude while it references my existing world-building. Need an NPC for a tavern scene? Claude can check my existing characters, understand the regional politics I've established, and suggest someone who fits the world I've built.

I stay in creative control while Claude handles consistency and mechanical details. I make the interesting decisions, which honestly is the fun part for me. This keeps me in flow instead of stopping to flip through notes or cross-reference details.

I remember seeing a post with something like "AI amplifies thinking, not just writing." That captures it perfectly. I'm not handing off the creative work, I don't want to! I'm removing the friction that breaks my creative momentum.

## The technical reality

This isn't complicated to set up. Install Claude Code, run it from your Obsidian vault directory, create a `CLAUDE.md` with your vault's conventions, optionally add custom commands in `.claude/commands/`.

No plugins required for the basic workflow. Claude's file access handles everything.

For more advanced setups, MCP servers can give Claude deeper vault integration. Search capabilities, metadata access, connections to other tools. But start simple.

## What makes this different

Other AI tools for Obsidian exist. Copilot, Smart Connections, various ChatGPT integrations. They work fine for chat-style interactions or semantic search.

Claude Code is different because it's agentic. It doesn't just answer questions. It'll edit a note, create a new one, move files around. It operates as an actual participant in my knowledge management system.

It can batch things across hundreds of files, chain workflows together, run stuff on a schedule. Custom slash commands encode complex procedures.

The vault becomes a workspace Claude actively maintains, not just a corpus it reads.

## The balance

I'm careful about what I delegate. Claude handles the grunt work like formatting, linking, research, organizing. This leaves me to decide what matters, make the creative calls, and review anything before it goes out.

This isn't about automating thinking. It's about getting stuff out of the way so I can actually think. When organizing notes feels effortless, I capture more. When research doesn't break my flow, I go deeper.

## Getting started

If you're curious about this workflow, start with one use case. Don't try to automate everything. Pick something annoying you actually avoid doing.

Write your conventions down. The `CLAUDE.md` file forces you to articulate how your system works. This clarity helps even without AI.

Keep humans in the loop. Review what Claude does. Git history helps here. Trust builds gradually.

Expect iteration. Your first commands won't be perfect. Refine based on what actually happens.

The useful part isn't the technology itself. It's having an assistant that understands your specific system.

## Where this goes

What's clear is that markdown-based knowledge systems and agentic AI fit together naturally. Your notes become context. Your conventions become instructions. There's less friction between saving something and actually using it.

For me, this solved a decade-long problem. I finally have a second brain that actually stays organized.

---

### How I'm orchestrating Claude Code workflows that actually work

Published: November 25, 2025 | Reading Time: 12 min read

I've been using Claude Code daily for months. Not casual use - actual production work across multiple projects. And the uncomfortable truth I keep coming back to: most people are using it wrong.

Not wrong in a gatekeepy "you're holding it incorrectly" way. Wrong in a "you're missing the entire point" way. The guides tell you to add subagents, configure skills, install MCP servers. They don't tell you why these features exist or how to make them work together. They definitely don't mention that adding more stuff often makes things worse.

## It's all about context

Claude's 200K token context window sounds massive until you actually use it. That window is your most precious resource, and it fills up way faster than you'd expect. Every file Claude reads, every search result, every back-and-forth - it all piles up. When context fills, quality tanks. Claude starts forgetting things. Missing instructions and making bizarre decisions.

Reddit is full of people complaining about Claude "forgetting what it was doing two steps ago" or "ignoring explicit instructions." Most of this isn't Claude being stupid. It's context pollution.

Once that clicked for me, the whole feature set made sense. Subagents? They're isolated context windows. Skills? Pre-packaged project or company specific context that loads on demand. MCP servers? External context sources and actions. Slash commands? Templated context injection.

Every single feature is about managing those 200K tokens. That's always what it comes back to.

## Quick feature rundown

The terminology is confusing, so here's the short version:

**Subagents** are specialized AI assistants that Claude delegates to. They get their own context window, totally separate from your main conversation. Built-in ones include "Explore" for searching your codebase and "Plan" for read-only research. When a subagent finishes, it hands off the refined results back to the main agent, and throws away its context.

**Skills** are capabilities that Claude decides when to use. You don't invoke them directly - Claude picks them up automatically based on what you're doing. Define them in `.claude/skills/` folders. For me, these are project specific. Things like how React components are structured, how API endpoints are named, coding conventions, that sort of thing. You could put this all in the CLAUDE.md file, but skills let you organize it better and keep it out of the main prompt, again, freeing up the precious context window.

**Slash commands** are prompts you save as Markdown files. Drop `commit.md` in `.claude/commands/` and now you've got `/commit`. Simple. I think of these as common commands or macros. Shit I type all the time and get sick of it. It's the steps where I've done some "humain-in-the-loop" type review and give the agent its next instruction (which is usually git commit, run an audit, create tests, etc).

**MCP servers** connect Claude to external stuff - databases, APIs, web search, your local browser, whatever.

**Hooks** are shell commands that fire at specific moments. Before a tool runs, after a tool runs, when a session starts. Automation hooks. I don't use these much honestly, but some good use cases are running linters and code formatters, unit tests, posting PR links to Slack etc.

## The thing that tripped me up for weeks

Descriptions drive routing.

I cannot stress this enough. Claude decides which subagent to use, which skill to invoke, entirely based on the descriptions you write. Write a bad description and Claude will never touch your carefully crafted tool. I watched people spend hours building the perfect agent, slap on a description like "A code review tool", then wonder why it never got used.

Bad: "Reviews code."

Good: "Invoke when reviewing code for security vulnerabilities, authentication issues, and data exposure risks. Use after completing feature implementation and before creating pull requests."

On the flip side of that, creating massive descriptions with every possible detail or comprehensive code or command examples is just a waste of context tokens. This is an art more than a science. You need just enough to guide the agent, while keeping the context tight.

The routing system needs to know *when* to use something. Telling it *what* something does isn't enough.

## What I actually use

Enough background. Here's my setup.

### Research subagent

This is the customization that changed everything for me. I have a "research" subagent wired up to context7, websearch, and fetch MCP servers. When the main agent needs to look something up - documentation, examples, what other people have done - it hands off to this research agent.

The magic is what happens after. The research agent doesn't dump everything back into my main conversation. It reads a bunch of stuff, figures out what matters, and returns a summary. Just the relevant bits.

Why bother? Because if the main agent did the research itself, all those search results and docs would clog up its context. By using a subagent with its own context window, the main conversation stays clean. The answer comes back. The noise doesn't.

It's like having someone go to the library, read ten papers, and come back with a one-page brief instead of dropping a stack of books on your desk.

### Slash commands I actually use

**`/do`** - My workhorse. Takes whatever I type after it and tacks on my standard stuff: which agents to use, formatting preferences, patterns to follow. Maybe 20 lines total. Saves me from repeating "use the research agent for lookups" on every request.

**`/commit`** - Git commits with my message format. I type `/commit`, it does the thing. No explaining my commit conventions every time and more consistent than trusting it'll always check the related Skill.

**`/audit`** - This one's more involved. It tells the main agent to walk through files one by one, handing each to an "audit" subagent. That audit agent checks against my standards - patterns, style, whatever I've defined. Doing it file-by-file prevents the context from exploding. Asking Claude to review your whole codebase at once is a recipe for garbage output.

**`/test`** - Same idea, but for testing. Dedicated test subagent that knows our frameworks.

Pattern: anything I type more than twice becomes a command.

### Skills for stuff I'm tired of explaining

I have a Docker skill for one project. It knows the compose setup, the environment variables, which ports go where. Without it, Claude tries to figure out Docker fresh every session. Gets it wrong half the time. Asks me questions I've answered dozens of times before.

With the skill, it just knows. I stopped explaining. The skill explains for me.

Skills are basically onboarding docs that Claude actually reads.

### MCP setup

Mine's focused on research:

- **context7** - pulls in docs and code context, examples
- **websearch** - google that shit
- **fetch** - grabs content from URLs
- **chrome tools** - lets Claude use my local browser for anything tricky or visual verification

MCP servers let Claude know things it wouldn't otherwise know. They're external brains, not just external tools.

## What works

**Write a plan before you code.** Everyone says this. It's annoying advice. It's also correct. One person I read about spent 2 hours on a 12-step implementation doc, then let Claude execute step by step. Saved 6-10 hours. The upfront planning feels slow. It's not.

**Delegate anything that would pollute context.** Research, code review, testing - hand it to a subagent. Keep your main conversation focused on one thing.

**Return summaries, not data dumps.** When a subagent finishes, it should give you conclusions. "Auth uses JWT with refresh tokens in httpOnly cookies" beats pasting the entire auth module.

**Review one file at a time.** Don't ask Claude to audit your whole codebase. It'll either refuse, phone it in, or fill its context with so much code it can't think. One file. Dedicated review agent. Repeat.

**Clear often.** Use `/clear` between unrelated tasks. Start a new conversation when you're past 60% context. Don't let your conversation become a junk drawer.

## How much autonomy is too much?

The community calls full autonomous mode "YOLO mode" - running `--dangerously-skip-permissions` and letting Claude do whatever. Some people swear by it.

I don't go that far. My approach:

- I decide what needs to happen
- Claude does the tedious parts
- I check before moving on
- Nothing ships without me looking at it

There's a post called "30 Days of Claude Code" that nails the tension: "I shipped more projects in 30 days than in the previous six months, but I was becoming a manager of AI output rather than a programmer."

That's the deal. You ship faster. You're also not really coding anymore - you're reviewing. Whether that's a win depends on what you care about.

I treat Claude like a fast junior dev with great memory but questionable judgment. It does a lot. I'm still responsible for what goes out.

## What doesn't work

**Adding tools without good descriptions.** You can install 50 MCP servers and 20 agents. If your descriptions suck, Claude ignores all of it. More features + bad routing = wasted effort.

**Letting conversations get bloated.** "Just one more thing" until Claude is confused and contradicting itself. Clear aggressively. Fresh conversations are cheap.

**Auto-accepting everything.** The speed is addictive. But I've caught bugs that would've shipped if I'd clicked accept without looking. Happens more than I'd like to admit.

**Giant prompts.** "Build me authentication with OAuth, JWT, password reset, and 2FA" will get you garbage. Break it down. One piece at a time.

**Expecting Claude to remember.** It doesn't. Not between sessions. That's what CLAUDE.md is for. If you're repeating yourself, write it down.

**Over-engineering before you start.** I've watched people spend days perfecting their Claude setup before writing any code. Start simple. Add stuff when you hit friction. Version five will be better than version one no matter what.

## The stuff that still sucks

Claude hallucinates. Makes confident claims about things that aren't true. Sometimes says it did something when it didn't. Better config doesn't fix this. You have to stay alert.

Context loss happens even when you're careful. I do all the subagent delegation, all the context hygiene. Claude still loses the thread sometimes. The compact feature can make it worse.

Quality varies day to day. Some sessions Claude feels sharp. Others it feels like it forgot how to code. Anthropic has confirmed bugs. Model updates change behavior. Something that worked last week might not work today.

And the uncomfortable question: are you learning less? If Claude does all the hard stuff, do your skills atrophy? I don't have a good answer. It's something I think about.

## If you're just starting

Don't overthink it.

1. **Set up CLAUDE.md first.** Document your project. Coding conventions. Common commands. Run `/init` to generate a starting point, then edit it. This one file makes a bigger difference than any other configuration.

2. **Add one slash command.** Whatever you type most often, make it a command.

3. **Build a research subagent.** Even a basic one that just does web searches in its own context window will clean up your main conversations.

4. **Use what's built in.** The Explore agent is already there. Get comfortable with it before building custom stuff.

5. **Add config when something annoys you.** Not before. Friction tells you what to fix.

## Where this goes

The tools will get better. Context windows will expand. Routing will improve. Half of what I'm manually configuring now will be automatic eventually.

But the core tension - automation versus oversight - isn't going anywhere. As these tools get more capable, the question of how much to trust them gets harder, not easier.

The developers who do well with this stuff won't be the ones who write the most code. Won't be the ones who hand everything to AI either. It'll be the people who figure out when to delegate and when to verify. Who treat AI as a tool, not a replacement for judgment.

Writing code isn't the hard part anymore.

---

Need some help with this stuff? Hit me up on [LinkedIn](https://www.linkedin.com/in/geekforbrains/) and lets nerd out together.

---

### Building an Estimate Agent with n8n, Notion, and Slack

Published: October 28, 2025 | Reading Time: 4 min read

![Scopeify in action](../../assets/images/scopeify_banner.png)

If you've ever run a services business, you know the drill. A great sales call with a potential client, ideas flying, excitement building... and then the inevitable, soul-crushing slump as you face the blank page of a new scope of work document. For my [business partner](https://www.nerdburn.com) and I, this initial scoping phase was a constant bottleneck. We had years of historical data, battle-tested calculations, and a clear methodology, but getting that first draft down always felt like pulling teeth.

We needed a superhero...

We needed an *agent*... 

We needed… **Scopeify** 🦸🏻. *(I know I know, the name's cheesy, get over it)*.


## What sucked
Our process was, frankly, a bit of a mess. After a promising sales call, we'd scramble to compile notes, remember key details, and translate them into a structured estimate. This often meant:

- **Delay:** Estimates took too long to produce, leading to missed opportunities.
- **Inconsistency:** Different projects started with varying levels of detail and structure. *(much to the dismay of our PM team)*.
- **Burnout:** The mental overhead of starting from scratch every time was draining.

We knew there had to be a better way. We needed something that could leverage our existing knowledge, integrate with our daily workflow, and get us 80% of the way there, fast. That's when the idea for Scopeify was born.


## How I was going to fix it

Enter, The Dream Team: n8n, Notion, Slack and a decent LLM

After scribbling on some paper for a few mins, I had a clear plan: an AI-powered assistant that lived in Slack, our primary communication hub. After a sales call, I wanted to simply message `@Scopeify` in a custom Slack channel (named #estimates, naturally), feed it project notes (either typed directly, linked Notion pages, or even automated notes from Google Meet), chat with it for clarity, and then command it to generate an initial estimate. And any teammember in that channel could hop in and help refine it!

Here's how I imagined the flow:

1. **Sales call:** Conduct the call, gather initial requirements.
2. **Slack integration:** Hop into #estimates, @Scopeify with call notes.
3. **AI interaction:** A quick back-and-forth for clarification.
4. **Estimate generation:** Scopeify reads a Notion template, our conversation, and any shared files.
5. **Notion output:** It spits out a URL to a new Notion page containing the initial estimate.
6. **Human in the loop:** I review, iterate with Scopeify in the Slack thread for minor tweaks, and then manually refine the final 20% in Notion.

This approach would get us off the ground quickly, allowing us to spend our valuable time on ~~another pour over ☕️~~ the project-specific nuances rather than the initial setup.

The n8n setup ended up being 4 different workflows. The primary "agent" workflow receives Slack messages and orchestrates the work, treating the other three workflows as tools the LLM can call: one reads existing estimates from Notion, another updates them, and the third creates new ones. This keeps the logic decoupled and easier to maintain and reuse in future.


![Scopeify in action](../../assets/images/scopeify_workflows.png)


## The "gotchas"
Building the core logic in n8n was fairly straightforward, but *(and there's always a "but")* Notion threw some curveballs.

### The 100-block limit: 
Notion, in its wisdom, treats every line of content as a "block." A bullet point is a block, a paragraph is a block, a heading is a block. And here's the rub: their API has a limit of 100 blocks per request when creating or appending page content. Our estimates, with all their detailed line items, assumptions, and deliverables, routinely blew past that.

This meant I couldn't just feed a beautifully formatted markdown document (which LLMs love) directly to Notion. I had to create a page with a title, then append content block by block, making multiple requests. This quickly became a headache.


### Markdown to blocks, and back again: 
LLMs are brilliant with markdown. They can generate complex, well-structured text effortlessly. Notion, not so much. This created a friction point:

- **Notion blocks to markdown:** I needed a way to convert our existing Notion template (and any Notion notes) into markdown that an LLM could understand.

- **LLM markdown to Notion blocks:** The LLM would generate the estimate in markdown, but then I had to convert that markdown back into individual Notion blocks, ready for insertion.

This back-and-forth conversion became a custom tool I had to build, essentially acting as a translator between the LLM's markdown fluency and Notion's block-based reality. Honestly, a fun challenge. Always love a reason to flex some nerd muscle.

### Dynamic blocks and custom n8n nodes:
The built-in Notion node in n8n is powerful, but it's designed for static block definitions. You specify the blocks you want to create at design time. Since Scopeify's estimates are dynamically generated by the LLM, I had no idea what blocks would be needed until runtime.

Instead of fighting with the built-in node, I pivoted to using n8n's HTTP Request node to call Notion's API directly. This gave me complete control to dynamically build the page request at runtime, assembling arrays of blocks (in 100-block chunks, of course) based on whatever the LLM generated. The flexibility to handle an unknown number and type of content blocks was worth the extra API wrangling.


## Ok, but did it work?
Despite the two weeks of "on and off" wrestling with Notion's quirks and finessing the n8n-Slack flow, the result has been transformative. Scopeify isn't just a tool; it's like adding another highly efficient staff member to our team.

With a relatively low effort of work, we're now:

- **Faster:** What used to take 40 hours of procrastination spread over 3-4 days now takes 10 minutes, same day.
- **More consistent:** Every estimate starts from a solid, data-backed foundation.
- **Less stressed:** That dreaded "blank page" syndrome is gone.
- **Closing more deals:** We've seen roughly 20% more deals close, thanks to faster turnaround and more professional estimates.

The "human in the loop" aspect is critical. I've mentioned that a lot before. AI is great as a tool, but its not a panacea. Scopeify handles the heavy lifting of assembly and initial data interpretation, getting us to about 80% completion. Then, my business partner or I step in to apply that final layer of project-specific insight, client rapport, and nuanced adjustments. It’s the perfect blend of automation and expert human touch.

If you need some help automating a workflow that grinds your gears, [hit me up](https://www.linkedin.com/in/geekforbrains/). I love this shit.

---

### From zero to Spotify in 48 hours: Building an AI country album

Published: October 15, 2025 | Reading Time: 5 min read

<iframe data-testid="embed-iframe" style="border-radius:12px" src="https://open.spotify.com/embed/album/4bWa0UxtaPciVFhuoNhOiP?utm_source=generator" width="100%" height="352" frameBorder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

I just released a country music EP on Spotify. The whole thing - from concept to live on all major streaming platforms - took 48 hours.

Here's the thing though. I've never recorded music professionally. Hell, I can barely play guitar beyond a few chords. But I wanted to understand what was actually possible with AI tools in 2025, so I created "Dale Tucker" to see how far I could take the idea.

No, this isn't another "AI is gonna replace all musicians" take. It's about understanding the tools from a builder's perspective. What works, what doesn't, and what you can actually ship.

## The challenge

My initial concept and goal was simple: create a complete 6-song EP using only AI tools and basic production software, then distribute it to Spotify, Apple Music, YouTube Music and Amazon Music. Timeline? 48 hours from start to finish.

Why? Because everyone talks about AI capabilities in abstract terms. There's a lot of blue sky and empty promises. I wanted to actually build something and see where the friction points were. Plus, the idea of becoming a country singer named Dale Tucker for a weekend sounded hilarious.

*Spoiler: I succeeded. But not without learning a few things along the way.*

## Opening the toolbox

![Screenshot of Suno](../../assets/images/suno_screenshot.png)

Before I could make anything, I needed to figure out which AI tools were actually worth using. Turns out there are a LOT of AI music generation tools out there. Too many.

I tested Udio, Suno, ElevenLabs, Mureka, and Soundraw. Each one promising to be the "game-changer" for AI music. Sound familiar? Just like the [Javascript ecosystem](http://localhost:8000/blog/year-of-nodejs) I wrote about years ago, AI tools seem to come out daily with everyone claiming theirs is the best.

After spending a few hours with each, I settled on ElevenLabs and Suno. ElevenLabs for voice training and generation, Suno for the actual music production. The others either lacked the control I needed, produced inconsistent quality, specialized in background music only (no vocals) or had interfaces that made me want to throw my laptop out a window *(looking at you, Soundraw)*.

This is probably the most important part of the whole experiment - don't just grab the first tool you find. Test them. Push them. See where they break. I would have wasted way more time if I'd committed to the wrong tools early.

## Building Dale Tucker

![Dale Tucker](../../assets/images/dale_tucker.png)

Once I had my tools, I needed to create a persona. This wasn't just about making music - I wanted consistency. If I'm going to create a "singer", that singer needs to sound like the same person across all six songs.

First step was training my voice in ElevenLabs. I recorded maybe 10 minutes of myself talking, reading, singing terribly. The tool analyzes it and creates a voice model. Pretty straightforward. The output quality was surprisingly good - it actually sounded like me, just with better pitch control than I have in real life.

Then I took that audio and used it to train a persona in Suno. The persona gave me vocal consistency, but it took a few songs to dial it in. I'd generate a track, listen to what worked and what didn't, then adjust. Once the persona felt right, I started combining it with Suno's style parameters.

This is where it gets interesting. The style parameter lets you define the type of music, vibe, BPM, and even the key or scale you want. I kept the style mostly consistent across all six songs - country/folk aesthetic, specific tempo ranges - but I could adjust the key per song depending on what felt right. One song needed G-minor pentatonic, another worked better in a different key entirely.

That level of control is what keeps AI-generated music from feeling like generic slop. Human-guided AI is powerful. The garbage you hear online is what happens when you let tools run unhinged without direction. My approach was deliberate - test, adjust, iterate, lock in what works.

Could I have skipped ElevenLabs and just used Suno's default voices? Sure. But then I wouldn't have learned how to chain tools together or maintain consistency across platforms. That's the kind of thing that matters when you're building real products.

## Writing songs with ChatGPT

Now for the creative part. I'm not a songwriter. I can write code and technical documentation, but lyrics? That's a different beast.

The whole project started with a joke. I made some comment about Mondays and coffee in our work Slack, and someone said it sounded like a country song. So "Monday, Again" became the first track. The rest, as you can see, is history.

I started pulling from actual experiences. "Trash Can Turkey" came from a family Thanksgiving camping trip where we literally cooked turkey in an upside-down metal garbage can surrounded by charcoal. "Look Up" was about everyone being glued to their phones - ironic coming from someone in tech, but it bothers me. You go out to eat and nobody's talking. They're all just staring at their devices. These tools are supposed to enrich our lives, not overtake them. I find that sad.

I'd write a rough concept, maybe a few lines I thought were decent, then hand it to ChatGPT.

"Make this sound like a country song about X, but keep it authentic, not cheesy."

The first attempts were garbage. Too generic. Too "AI" sounding. But here's what I learned - you have to iterate. I'd take ChatGPT's output, mark what I liked, what felt fake, and ask for revisions. Sometimes this took 10-15 rounds per song. The goal wasn't to let AI write the song, it was to use AI as a collaborative tool to get to something I'd actually write if I knew how. I think that's an important distinction. 

By song three, I had a process down. Give the tool context about the emotion I wanted, examples of phrases that felt right, and very specific direction about what to avoid. The lyrics ended up feeling genuine because I put in the work to make them mine. This had the surprising effect of me also falling in love with my own country music. Weird...

## Production and distribution

Once I had the six songs generated from Suno, they needed work. AI generates decent tracks, but they're not mastered. The levels are all over the place. Some have weird artifacts or glitches.

I pulled everything into Logic Pro and spent a few hours EQ'ing and mastering. This is where having some technical audio knowledge helps. Could someone without that experience do it? Probably, but it would take longer. YouTube has enough tutorials to figure it out.

![Screenshot of mastering in Logic Pro](../../assets/images/logic_pro_screenshot.png)

For album art, I used Google's Gemini "Nano Banana" model. I wanted a photo of me as a cowboy in a wheat field with a guitar. But here's the smart part - I used an actual photo of myself as reference. This way, if I need more promotional images later, I can maintain consistency by using other photos of myself in different poses. The AI just adds the cowboy aesthetic and environment. AI is notoriously bad at consistent human models.

The final step was distribution. I used DistroKid for this. Upload the tracks, add metadata and lyrics, select which platforms you want, pay a small fee, and you're done. Within 48 hours, Dale Tucker was live on Spotify, Apple Music, YouTube Music and Amazon Music.

No record label. No producer. No studio time. Just me and a collection of AI tools.

Lets just pause and think about that for a second. 

## What actually matters here

This experiment wasn't about proving I could make music. It was about understanding AI tool integration, workflow design, and where the human still matters.

**Tool selection is critical.** I could have stuck with the first tool I tried and probably produced something. But it would have been worse and taken longer. Take time to evaluate.

**Workflow design matters more than individual tools.** The fact that I could use ElevenLabs output to train Suno personas? That's workflow thinking. Most people would use each tool in isolation and miss those integration opportunities.

**AI augments, it doesn't replace.** Every song required dozens of decisions from me. Which lyrics to keep, what musical direction to take, how to master the final tracks. The AI did the heavy lifting, but I did the decision making. The "human touch".

**Consistency requires strategy.** Using reference photos, trained personas, and specific musical parameters wasn't accidental. It was necessary to make this feel like a cohesive project rather than random generated content.

**Speed to market has fundamentally changed.** What used to take months now takes days. That's not hyperbole. Dale Tucker went from concept to streaming in 48 hours. The implications for rapid prototyping and iteration are massive.

## Why this matters for development work

You might be wondering why a tech nerd like me cares about AI music generation. Fair question.

The principles are the same. Whether you're building a music project or a client app, the skills are identical:

- Rapid prototyping and iteration
- Tool evaluation under pressure  
- Workflow integration across platforms
- Understanding where AI helps and where it doesn't
- Shipping complete projects, not just demos

These "fun" experiments teach you things you can't learn from documentation. You hit real problems. You have to debug. You have to make trade-offs. And you learn what's actually possible versus what's marketing hype.

Plus, clients don't want to hear about your theoretical AI knowledge. They want to see what you've built. Dale Tucker is proof you can take an unfamiliar domain, learn the tools quickly, and ship something complete.

## Final thoughts

Did I become a real country singer? No. Is Dale Tucker going to top the charts? Absolutely not. But that was never the point.

The point was to understand what's actually possible with AI tools in 2025 when you approach them systematically. And the answer is: a lot more than most people think.

I spent two days creating an entire music project from scratch with no prior experience. The tools are good enough now that domain expertise matters less than systematic thinking and willingness to iterate.

Will I make more Dale Tucker songs? Maybe. It was genuinely fun. But more importantly, I learned things about AI implementation that I can apply to actual client work. That's the real value.

If you're interested in what AI could do for your project, or if you want to chat about rapid prototyping and tool integration, [reach out](https://www.linkedin.com/in/geekforbrains/). Lets build something fun together.

And if you want to hear what 48 hours of AI music generation sounds like, [Dale Tucker is on Spotify](https://open.spotify.com/album/4bWa0UxtaPciVFhuoNhOiP?si=t4nyIjm8RvOufHlP3mXswQ). Fair warning - it's definitely country music.

---

### How we automated our newsletter link curation with n8n, Python and AI

Published: August 7, 2025 | Reading Time: 6 min read

![n8n Workflow Screenshot](../../assets/images/linkslacker.png)

Remember that tedious task you keep putting off because it takes forever but still needs to get done? Yeah, we had one of those. Every week, our teammate Elysse would spend days combing through our Slack channels, clicking on every shared link, figuring out what the hell each one was about, and crafting clever one-liners with emojis for our newsletter (to her credit, she kicked ass at it).

It was soul-crushing work. But it was also important because these curated links are a key part of our weekly newsletter and feed content for our [Internet Plumber podcast](https://www.internetplumber.co). So I did what any self-respecting developer would do: I automated the absolute shit out of it.

## The manual process that was killing us

Here's what had to be done every single week:

1. Go through our #code, #design, and #ai Slack channels
2. Find all the links shared in the past week
3. Click on each link (we're talking 20-30 links here)
4. Actually read/understand what the content was about
5. Write a witty one-liner that captures the essence
6. Pick the perfect emoji to go with it
7. Add everything to our Sanity CMS for the newsletter

This wasn't a one-sitting kind of task either. It was periodic on and off work throughout the week, constantly interrupting other projects. The mental context switching alone was brutal.

## Enter the automation stack

I knew we could do better. The solution came in the form of three tools working together:

- **[n8n](https://n8n.io)** for workflow orchestration
- **Python** for web scraping (in its own container, because I'm fancy like that)
- **AI** for content understanding and copywriting

Let me break down how these pieces fit together.

### n8n: The conductor

I decided to self host n8n because I like having full control (and also because I'm cheap). Spun the whole thing up inside Docker, which sounds way more impressive than it actually was. If you haven't used n8n before, think of it as Zapier's more technical cousin. You know, the one who actually knows how to code.

The workflow starts by connecting to our Slack workspace and scanning the defined channels (#code, #design, #ai) for any messages containing links from the past week. This gives us a nice clean list to work with.

### Python: The heavy lifter

Here's where I got clever (or carried away, depending on how you look at it). Instead of trying to make n8n do everything, I created a dedicated Python container that sits alongside it. From n8n, I just call out to Python whenever I need to do something that n8n can't handle natively.

For each URL, my Python script:

- Fetches the page content
- Handles all the edge cases (redirects, timeouts, weird encodings)
- Extracts the meaningful content, stripping away navigation, ads, and other cruft
- Hands the clean data back to n8n to continue the workflow

This setup gives me the best of both worlds. n8n handles the visual workflow stuff beautifully, but when I need to drop down and do something specific (like parse some janky HTML), I've got Python ready to go. No more trying to shoehorn complex logic into n8n's nodes.

Websites are messy. Some load content dynamically, others block scrapers, and don't even get me started on sites that render everything client-side. But with enough error handling and fallbacks, we get usable content from about 95% of links. The other 5%? Well, that's what the human review is for.

I love me some Python.

### AI: The creative brain (and occasional comedian)

Here's where the magic happens. We feed the scraped content to an AI model with a carefully crafted prompt that basically says: "You're a witty tech newsletter writer. Summarize this content in one punchy sentence and pick an emoji that captures the vibe."

The results? Surprisingly good. Sometimes even better than what us humans come up with at 4pm on a Friday. The AI picks up on technical nuance, understands context, and occasionally drops a genuinely funny line. Though it also sometimes thinks a blog post about database optimization deserves a party emoji. 🎉

## The beautiful result

What used to take days of scattered work now runs in about 30 seconds. Every Friday morning, our workflow:

1. Scans the defined Slack channels
2. Finds all shared links
3. Scrapes each website
4. Generates descriptions and emojis
5. Pushes everything to Sanity CMS as a draft for human-in-the-loop review

That last bit is important. We keep a human (yes, its still Elysse) in the loop. The content lands in our CMS as a draft where someone can review it, tweak any descriptions that miss the mark, and ensure nothing weird made it through. It's the perfect balance of automation and human oversight.

## What this means for our team

The time savings are obvious. We're talking days of work compressed into seconds. But the real win is what the team can do with that reclaimed time. Instead of mind-numbing link clicking, they can spend more time on strategic content and engage with our community.

Plus, the consistency is a game-changer. The automated system never misses a link, never forgets to check a channel, and processes everything with the same level of attention. No more "oh shit, I forgot to check the #ai channel this week" moments.

## The gotchas

As usual, it wasn't all rainbows and unicorns 🦄. Some "fun" challenges we hit:

- **Rate limiting**: Turns out websites don't like it when you slam them with requests. Who knew? Had to add delays and actually respect robots.txt like a good citizen
- **Dynamic content**: Sites that load everything via JavaScript are the bane of my existence. Special handling required, and by special I mean "painful"
- **AI hallucinations**: Sometimes the AI would completely misunderstand content and write something bonkers. Like describing a serious security vulnerability as "spicy" 🌶️
- **Character limits**: Newsletter platforms have limits, so descriptions needed to be concise. The AI's first drafts read like novels

But these are solvable problems. A bit of retry logic here, some prompt engineering there, and we had a mostly robust system. The Docker setup actually helped here because when things inevitably broke, I could debug the Python container separately without taking down the whole workflow.

## Should try automation?

If you're drowning in any repetitive content curation task, absolutely. The stack we used (n8n + Python + AI) is accessible and powerful. You don't need to be a machine learning expert or a Python wizard to make this work.

The key is starting simple. Maybe you don't need to scrape websites, just organizing links might be enough. Maybe you don't need AI, extracting titles and meta descriptions could work. Build the minimum viable automation and expand from there. Trust me, your first version doesn't need to be perfect. Mine sure as hell wasn't.

The tools are there. n8n is free to self host, Python containers are easy to spin up, and AI APIs are cheaper than a developer's hourly rate. The question is: what soul-crushing task are you going to automate next? Because I guarantee you've got at least one.

---

Tired of building the same automations over and over? Our team at [Input Logic](https://inputlogic.ca) specializes in workflow automation and custom integrations. Let's talk about killing your repetitive tasks for good. Ready to take back Friday?

---

### How to choose a platform for your mobile app

Published: July 7, 2020 | Reading Time: 5 min read

![Choosing a Mobile Platform](../../assets/images/choices.webp)

Launching an app is an exciting business endeavour but is also rife with tough decisions; many of which can quickly derail progress and send you into a financial tail spin.

One such decision is the technology or platform on which to build. While there are only really two players for mobile operating systems, iOS and Android, there are an array of choices on how to build upon them. This is a common question from [my clients](https://www.inputlogic.ca/work) and one I encourage them not to take lightly.

In this article I'll outline 4 major options with pros and cons of each. By the end, you'll be ready to make an educated decision about which platform to build your app on.

## The 4 mobile platforms

While there are technically more than 4 options out there, these are the leaders from which we choose time and time again. Each offers its own unique benefits (and pitfalls).

### Platform specific (aka: Native)

Developing for each OS (operating system) in its native language is of course the most supported and most performant. It's also the most expensive. This is because you'll be writing the app in a separate language for each. The two players are iOS (written in Swift or Objective-C) and Android (written in Java or Kotlin). While there are developers that can code in both, you're much more likely to end up hiring one for each, doubling your overhead. Native apps are the best choice when they have high performance or memory requirements, OS specific libraries not supported elsewhere or games.

**Key take aways:**

👍 Most performant

👍 Best support for leveraging hardware functionality

👎 Most expensive

### React Native

React Native (often abbreviated as RN) is a popular choice and is sort of a blend between Native and "Web". The majority of the code written is shared across both iOS and Android with a few select cases when handling functionality specific to each operating system. This results in a significant reduction in cost and timeline. Because React Native is written in Javascript, it can quickly become unwieldy and hard to debug if not managed by experienced developers. Shooting yourself in the foot is amazingly easy. Still, with the right team, RN is a fantastic choice and one we use often.

**Key take aways:**

👍 Majority of code is re-used across both OS's

👍 Significant cost and time savings

👎 Hard to debug, easy to shoot yourself in the foot

### PWA

Progressive Web Apps (PWA's) are exactly what they sound like; apps that work via the web. Instead of installing the app on your phone from the App Store, you can access them via the browser on your phone. This has some significant advantages. The biggest is the ability to use stable and well known web languages with 100% code sharing. There are a few drawbacks however. Most notably you won't be able to install the app from the app store and offline capabilities are very limited with iOS (Android has full support). We often use PWA's when timelines and budgets are a concern or when a client is still validating the concept with a basic offering (also known as a MVP).

*It should be noted there are ways of wrapping a PWA in a Native "shell" in order to install on the App Store or use hardware functionality. In these cases, we believe using React Native is a better choice than wrapping the PWA.*

**Key take aways:**

👍 Works on all devices with a single code base

👍 By far the cheapest

👎 No App Store, limited functionality and offline capabilities

### NoCode

The #NoCode movement is relatively new to the industry and is a way of using other existing tools to "mashup" an app by piecing them together in interesting ways. As the name implies, there is no (or very little) coding involved. Each of the tools you use will have their own monthly licensing fee, which can add up quickly. We like to use NoCode for proof of concepts or when building tools for a client that will be used internally. A good example might be a an inventory tracking system for a shipping and receiving company. More often than not however, these are quickly outgrown and a custom app is developed.

**Key take aways:**

👍 Fastest way to market

👍 New options popping up daily

👎 Monthly licensing can get expensive quickly, outgrown quickly

## Where to go from here

When choosing a platform its important to ask a few questions:

- What is your budget?

- What is your timeline?

- Does the app need to work on iOS, Android or both?

- Does the app need offline capabilities?

- Will the app require hardware functionality such as GPS or Bluetooth?

If you have a tight timeline and budget, going with a hybrid approach using React Native or PWA is probably your best bet. If you have a bit of budget, hardware requirements and need it to run on both OS's, React Native is a good choice. If you have specific hardware requirements not supported by other tools or high performance requirements then Native is basically your only option.

Hopefully after all that you have a better understanding of how to choose the best platform for your app. Its important to remember that, regardless of what you choose, you can always change it later. Yes sometimes that can be more expensive, but not launching at all or choosing the wrong platform to start will stop you before you even get started.

---

### After a year of using NodeJS in production

Published: November 2, 2017 | Reading Time: 5 min read

This is a follow-up to my original post, "Why I'm switching from Python to Node.js". I wrote it just over a year ago in response to my frustrations with Python and why I was going to try Node instead.

Fast-forward a year of in-house CLI tools, client projects and updates to our company's products and this is what I've learned. Not only about Node, but Javascript in general.

## Easy to learn, impossible to master

Node is so easy to learn. Especially if you already know some Javascript. Google a few beginner tutorials, play with Express and you're off to the races, right? Then you realize you'll need to settle on a database. No problem, lets search NPM. Oh, theres a handful of decent SQL packages. Later you realize all the ORM tools suck and a basic driver is your best bet. Now you're stuck implementing redundant model and validation logic. Shortly after that, you start writing more complex queries and start getting lost in callbacks. Naturally you read about callback hell, chop down your christmas tree and start using one of the many promise libraries. Now you just "Promisify" all the things and grab a beer.

All this to say that it feels like the Node ecosystem is constantly moving. Not in a good way. New tools that "trump" old tools seem to come out daily. Theres always a new shiny thing to replace the other. You'll be surprised on how easily this happens to you and the community seems to encourage it. You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts!

Packages that consist of trivial code no more than 10 lines of code are downloaded in the thousands every day from NPM. Seriously!? You need a dependancy for array type checking? And these packages are used by some huge tools such as React and Babel.

You'll never master something that moves at break-neck speed, not to mention the potential of dependancy instability.

## Good luck handling errors

Coming from other languages such as Python, Ruby or PHP you'd expect throwing and catching errors, or even returning an error from a function would be a straightforward way of handling errors. Not so with Node. Instead, you get to pass your errors around in your callbacks (or promises) - thats right, no throwing of exceptions. This works until you're more than a few callbacks deep and trying to follow a stack trace. Not to mention if you forget to return your callback on an error, it continues to run and triggers another set of errors after you returned the initial one. You'll need to double your client invoices to makeup for debug time.

Even if you do manage to come up with a solid standard for your own errors, you cant confirm (without reading the source) that the many of the NPM packages you have installed follow the same pattern.

These issues have lead to the use of "catchall" exception handlers that can log an issue and allow your app to gracefully shit its pants. Remember, Node is single threaded. If something locks up the process, everything comes crashing down. But its cool, you're using Forever, Upstart and Monit right?

## Callbacks, promises or generators!?

To handle callback-hell, error handling and general hard-to-read logic, more and more developers have started using Promises. These are basically a way to write what looks like synchronous code without crazy callback logic. Unfortunately, there isn't any one "standard" (like everything else in Javascript) for implementing or using Promises.

The most notable library right now is Bluebird. Its quite good, fast and does a nice job of making things "just work". However, I find having to wrap my requirements in Promise.promisifyAll() extremely hacky.

For the most part, I ended up using the excellent async library to keep my callbacks at bay. This felt more natural.

Nearing the end of my experience with Node, Generators become more popular. I never really ended up getting too deep into them and thus don't have much to give feedback on. Would love to hear someones experience with them.

## Bad standards

The last thing that I found frustrating was the lack of standards. Everyone seems to have their own idea of how the above points should be handled. Callbacks? Promises? Error handling? Build scripts? Its endless.

Thats just scratching the surface too. Nobody can seem to agree on how to write standard Javascript either. Just do a quick Google of "Javascript Coding Standards" and you'll see what I mean.

I realize that many languages don't have a strict structure, but they DO usually have a standard guideline created by the actual maintainers of the language.

The only one I thought was any good for Javascript is written by Mozilla.

## Final thoughts on Node

I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.

Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.

I would however recommend Javascript for front-end development such as Angular or React (like you have another choice).

I would also recommend Node for simple back-end servers mainly used for websockets or API relay. This can be done easily with Express and we do exactly that for our Quoterobot PDF processing server. Its a single file containing 186 lines of code including white space and comments. It does its job damn well too.

## Back to Python

So you might be wondering, what am I doing now? For now, I'm still writing the major parts of our web products and API's using Python. Mainly in Flask or Django using either Postgres or MongoDb.

Its stood the test of time, has some great standards, libraries, its easy to debug and performs very well. Sure it has its warts. Everything does when you start writing in it. For some reason Node managed to catch my eye and draw me in. I don't regret trying to embrace it, but I do feel like I wasted more time than I should have.

I hope Javascript and Node improve in the future. I'd be happy to revisit it.

Whats your experience? Have you run into similar issues that I did? Did you end up switching back to a more comfortable language?

---

Sick of fighting to get your web or mobile product launched? Our team at Input Logic can help your realize your vision and bring it to production.

---

### Starting your Django project on the right foot

Published: April 6, 2017 | Reading Time: 5 min read

![Django Starter](../../assets/images/django-starter.png)

We build a lot with Django. It's one of our favorite frameworks, along with Flask, Rails and Phoenix.

A common headache of any new project is prepping for local dev, production configs, and sane test integrations.

To help solve this, we create "starter projects". They're hosted on GitHub. To use them, simply fork the project and get to work.

Today, I'd like to share our Django Starter project.

You can find the GitHub repo [here](https://github.com).

## Local dev

First out the gate is local development. How do we run the project? Virtualenv? Vagrant? Docker? Which is our default database and what are the credentials?

We prefer to use Virtualenv. We like its support for both Python 2 and 3 and is much simpler than Vagrant or Docker. Python 3's venv is cool but isn't backwards compatible.

For our database, we use Postgres. That simply comes down to team familiarity and that we like to use Heroku for almost all deployments. Each database is named after the project and everyone has a postgres superuser that can create and migrate tables. With this approach, the local file can be identical across all workstations and makes sharing dev credentials much easier.

## File structure

### Apps

There are a few methods for organizing Django. The most common two are having Django apps at the root level or within an apps/ subdirectory. We prefer the latter.

There are two reasons for this:

1. It makes the top level structure much easier to read and traverse
2. It helps decouple app specific logic from other "general" modules

Each app also contains all of its own logic, including tests. Some teams prefer to have a dedicated tests directory. Our approach is to keep each area of functionality nicely encapsulated. If you're working on that area of the project, theres only one place to look. No surprises.

Here's a quick example:

```
apps/
  someapp/
    views.py
    tests.py
    ...
libs/
  filters.py
  ...
project/
  settings/
    common.py
    local.py
    production.py
```

### Settings

The default settings.py file is broken into a settings/ subdirectory with common (global) configs and environment specific configs. This aids in local development and production specifics while sharing common configs across both. Without this, the standard settings file quickly becomes unwieldily and hard to read.

### Libs

Anything that isn't specific to an app should go into the root libs directory. This is typically where we'd have custom modules for handling template helpers, project (not app) specific logic, etc.

For the most part, each bit of functionality is put in one file. One exception to this is template filters, where all of them exist in one.

### Logging

Logging is notoriously difficult to get right in Python and Django. Due to this, we wanted to have a standard that would work across local as well as production.

Our logging configuration is specified in the "common" config file and addresses each area of the project including Django itself, apps and celery tasks. Having each broken into their own setup allows us to easily dial up the logs in different areas while completely hiding them in others.

This has a few beneficial side effects:

- Common logging formats across all our projects, making it easier to scan logs when debugging
- Developers are less inclined to use print statements because they can't get the log to work
- Log output can be updated in a single location, whether we want to stream to stdout or a 3rd party service like Papertrail

### Worker queues

Not all our projects require background jobs, but we decided to include some examples since not everyone is familiar with the setup.

Our preferred tools are Celery and RabbitMQ. When these aren't used in the project, we simply delete the related celery and task files.

Worker queues are typically used for batch processing. This might be image resizing, bulk emails, Twilio text messages or multi-chain API calls.

Because we use Heroku, spinning up a fleet of workers becomes a trivial step instead of spending unecessary time configuring containers or EC2 instances. Just update the Procfile and you're good to go.

### Testing

We like to keep tests simple and focused. If you need to start testing your tests, you've gone too far.

We use the default Python unittest along with Django's TestCase suite. FactoryBoy and Faker are used for simplifying test data.

Lastly, we use TravisCI for running tests against our pull requests, which helps keep our development cycle tight.

## Production

Our preferred method of production is to use Heroku. To that end, we include a default Procfile which includes the common patterns for web and worker dynos.

After a bit of environment config housekeeping, deployment is as easy as `git push heroku master`

When it comes time to hand-off the project to our clients, transferring ownership is instant and doesn't require any changes. Whats not to like?

## Future plans

Thats what we've got so far and its been working great. We plan to add a few additional things. Mostly related to front-end.

At the moment we reach for React first. We're thinking of either adding some NPM build scripts and examples to the project itself or a dedicated React starter project that can be dropped into any of the framework starters we make.

We also plan to creating some starter projects for Phoenix and Flask.

---

If you're looking for some help on your next project, hit up our team at Input Logic. We focus on product development and would love to dig into your ideas and make them a reality.

---

### Merging local & server collections in MeteorJS

Published: February 18, 2017 | Reading Time: 5 min read

Up to this point, you've been working with Meteor and its collections with ease. Publish here, subscribe there. Then it happens. The app you're working on has a combination of local (client) and server related collection data that needs to be displayed in a merged list within your template. Now what?

The real world example of this happened to me a few days ago. I was working on a simple chat tool within a client project. The chat would have a "bot" that responds to keywords inline like any other message. The problem is, I didnt want to send those bot "messages" to the global message collection when only the local user would be consuming them. My goal was to combine the messages of all users as well as local messages of the bot into a single collection that could be displayed in the chat window.

Note that the following examples assume you know how to publish Meteor collections and put the right code in their specific client or server areas.

## The Wrong Way

You might be thinking the "right way" to do this is to fetch both sets of documents and merge the arrays using Underscore.js' sortBy function.

```js
Local = new Mongo.Collection(null); // Local, client only 
Items = new Mongo.Collection('items'); // Global, everywhere 
Meteor.publish('items', function() {   
  return Items.find(); 
}
Template.listItems.helpers({   
  items: function() {     
    var local = Local.find().fetch();     
    var items = Items.find().fetch();     
    var combined = local.concat(items);     
    return _.sortBy(combined, function(i) {return i.timestamp});   
  } 
});
```

You'd be wrong. There are a couple issues with this approach:

### Wasteful Queries

The first issue is every time either collection changes, both need to be re-fetched and combined. Depending on the size of your array and number of changes happening, this can be very intensive.

### Limited Filtering

While you can sort by the timestamp ascending, what happens when you need a more complex sort? You could of course add that logic to the helper, which will now also be re-run every time either local or global collection changes. Are your hacker-senses tingling? They should be!

## The Right Way

The best way to manage these two result sets is to combine them into a single collection that can be queried and filtered as needed.

```js
Local = new Mongo.Collection(null); // Local, client only 
Items = new Mongo.Collection('items'); // Global, everywhere  
Meteor.publish('items', function() {   
  return Items.find(); 
}  
Template.listItems.onCreated(function() { 
  Meteor.subscribe('items');   
  Items.find().observe({     
    added: function(item) {       
      Local.insert(item);     
    }   
  }); 
});  
Template.listItems.helpers({   
  items: function() {     
    return Local.find();   
  } 
});
```

The key difference here is the use of the .observe function. Every time a new global item is added, we insert it into the local. We then return the cursor for the local collection and work with it like any other collection.

The real beauty is in the ability to filter at will. First, we can filter the global subscription and query in the templates onCreated callback. This way we can really drill down to only the data we need. Second, we have the full sorting and querying ability of a collection right on our client.

---

### How to use Dropbox and Git for private repos

Published: January 10, 2017 | Reading Time: 5 min read

I love GitHub, especially for open source and team projects. However, sometimes I want to develop an app personally, but don't want to release it as open source and don't want to pay for GitHub premium. What to do?

The solution is quite simple actually. Create the base repo in your cloud drive of choice. In my case this is Dropbox. However, you could easily use Google Drive, Microsoft SkyDrive etc. All we're doing is referencing paths on your local computer, the cloud services do the rest.

### Step 1 - Setup the base repo

Create the initial base repo wherever you want it to be stored. I keep this in Dropbox.

```sh
git init --bare ~/Dropbox/myrepo.git
```

### Step 2 - Add Git to your project

Now, inside the project you've been working on (or an empty project directory if you haven't started yet), setup Git and add the initial files

```sh
cd ~/MyProject 
git init 
git add --all 
git commit -m "Initial commit"
```

### Step 3 - Add your (Dropbox) remote

Inside your project, you'll want to be able to push commits to your new Dropbox repo. To do that, we add a new remote. Still inside your projects directory from Step 2, run:

```sh
git remote add origin ~/Dropbox/myrepo.git
```

### Step 4 - First push

Almost finished! Make your first push. At this stage I like to set the upstream so I can just type git push instead of git push origin master.

```sh
git push --set-upstream origin master
```

Now as you work on the project, you can simply do:

```sh
git push
```

Boom! Private repos synced to the cloud and free thanks to tools such as Dropbox or Google Drive.

---

### A nerd's guide to using Evernote effectively

Published: October 24, 2016 | Reading Time: 5 min read

I love Evernote. So much that I store everything from my bookmarks using Evernote Clipper, code snippets I regularly use in my programs to my wedding plans and favourite recipes.

However, with all that data, you need to ensure you're indexing your content correctly so it can be easily found again. Think of it as Google for all your stuff. If properly indexed, anything you need is a few key strokes away. If not, well good luck finding that note about which type of fruit your mother in-law is allergic to before she arrives for dinner.

### Setup a default, "catch-all" notebook

The first step to organizing your Evernote is to setup a default "catch-all" notebook. This is where you quickly store notes for later tagging. It's also the default notebook when sending emails to Evernote (a great feature I'll cover in a minute).

Most people will name this Notebook "!inbox". The reason for the exclamation at the beginning is to ensure its always displayed at the very top when sorted alphabetically. It will always come before notebooks starting with number or letters.

Make a habit of processing any notes in your catch-all notebook next time you're on your computer.

### Less notebooks, more tags

Adding too many layers of complexity defeats the purpose of being able to easily find the information you need. Everything that can be done with notebooks, with a few minor exceptions, can be done with tags. Still, I see many people using tons of Notebooks. There's no need!

I only have three notebooks.

- !inbox (my catch-all)
- personal (anything and everything non-work related)
- work (anything work related)

Thats it! The rest is done with tags. In my "personal" notebook I have thousands of notes! You might be thinking "how the heck can you find anything!?". The key is proper tagging.

### Proper Tagging Technique

In order to find and sort your notes, you'll need to come up with some "tagging techniques". I use at least two tags. One will be the "type" and the other a "descriptor". Often you'll have multiple descriptors and sometimes multiple types.

Lets say I found a great asian recipe online. I would tag it with "recipes" (the type) and "asian" (the descriptor). The first step is to figure out the "type" of note. The type, I find, is the name most people would use for a notebook. So if your instinct would be to create a "Recipes" notebook, you know your tag needs to be "recipes" instead. The second is the descriptor. This ones a little harder. Because Evernote already provides a powerful search that indexes all contents of your note, you need to be careful not to tag redundant information. Lets use the asian recipe as an example. We'll assume the recipe is for a spicy stir fry. We could tag this with "stir-fry" and "spicy" in addition to "asian" but those keywords already exist in the note itself. Simply searching your notes for "spicy stir fry" that have been tagged "recipes" and "asian" would yield the same result. Also note that if you had a "western" spicy stir fry, it wouldn't show up.

Lastly, normalize your tag names. I like to always use lowercase and dashes in place of spaces. So "Stir Fry" becomes "stir-fry" and "Recipes" becomes "recipes". If you like it the other way around, go for it! The key is to be consistent.

### Learn to use the search bar

The search bar, in combination with tagging, makes it very easy to quickly perform searches on all your notes. To search for keywords with a specific tag you can do:

```sh
tag:recipes tag:asian spicy stir fry
```

Typing that into the search bar will search all notes tagged with "recipes" and "asian" for the keywords "spicy stir fry". The search bar has many other syntax options for filtering your notes. Play around with it to see what it can do!

### Create shortcuts for common tags

If you find yourself constantly looking up notes under a single tag, make it a shortcut! To create a shortcut in the Evernote desktop client, drag a tags name to the bar on the left. Now you can click that shortcut anytime you want to browse that tag specifically!

### Use email

I can't stress how important this one is. I use it a couple times per day! Evernote allows you to create a private Evernote Email Address that you can email anything to. It will convert all emails to notes automatically. Not only is this a great way to store important emails that arrive in your inbox (think vacation itineraries, legal documents or shared recipes), but its also a great way to store information you find on your mobile device. For example, when I find a great article on my iPad, I'll use the "Email To" function to send the article to my Evernote email address. This arrives at my catch-all "!inbox" notebook as a link. Next time I'm at my computer, I open the link in my browser and save the article using Evernote Clipper so the entire articles contents are now saved as a note and available anytime I need it.

Use your imagination and have fun! You'll quickly find that Evernote is a great way to store anything in your digital life!

How do you use Evernote? I'd love to hear about it.

---

### Why I'm switching from Python to NodeJS

Published: October 24, 2016 | Reading Time: 5 min read

Old news right? Who isn't switching to Node these days? It seems like the new kid on the block is converting devs by the masses. I'm one of them, and here's why.

Update: I wrote a follow-up post to this one: After A Year Of Using NodeJS In Production.

## Python 2, or is it 3?

The lack of focus and movement between Python versions is a massive pain the ass. Yes, I know lots of libraries are being converted or have been already. However, the lack of focus and clear direction of one over the other has my confidence in it at an all time low. I know this has more to do with the community not wanting to move, than the devs, but community is what drives a project.

## Unicode Support

Have you ever tried working with Unicode in Python? Holy shit its painful. Yes there are lots of docs on the subject, but it shouldn't be that convoluted. Python 3 is a move in the right direction, however. I'm not saying Node or Javascript are the gems in this category, but they definitely have better options.

## Circular Imports

Circular imports are the bane of any Python programmer and in my opinion are a very poor architectural choice for the language. I realize for the most part, circular imports are a sign your module design is broken. However, if you're an experienced developer, you'll likely spend more time shoehorning Python into your advanced patterns than anything else. Good luck with that. Node.js allows me import modules wherever the hell I want.

Side note: apparently Go has this limitation too. That makes me sad :(

## NPM vs PIP

Python has PIP, which is great. However, I frequently find more up-to-date and modern modules on NPM. With the ease of sharing on NPM comes the crap too, so you need to watch out for that. I always thought sharing on PIP was annoying, but found NPM to be easy peasy. I shared my first module in all of 5 minutes.

## Efficiency = more beer money!

Theres no doubt about it. Node is leaner than Python when it comes to hardware (if written properly). Being able to actually utilize lower end hardware and produce acceptable results is a major plus. A lot of that comes down to Nodes async nature. Yes I'm aware of Twisted and similar libraries. Have you ever actually written an async app in one of those? When building a product, speed of development is important but so is keeping overhead low. We can run the same Node project on half the hardware Python required.

## Team Familiarity

This one is always up for debate, but I like the fact the entire team usually knows Javascript at a basic level. This means they can look over Node code and get an understanding of whats going on. If they're a front-end dev, that means hooking up to API endpoints or handling views is a lot easier. Which also means less interruptions for me to help them. Yay!

## MongoDB and JSON

We love MongoDB and JSON. Node uses these two without even thinking about it. Obviously this can be done with other languages, but the ease of it is just so damn appealing I had to mention it.

## Its just Javascript

If you love Javascript like I do, this is a plus. If you hate it, not so much. I think Javascript is fun because its so expressive. There are so many ways to do something, which is great for applying specific strategies to key problems. I suppose this also spawns stupid debates like "adding semicolons vs no semicolons". For the record, I'm pro semicolons.

## Conclusion

To be clear, I still love Python. Its been good to me over the years and I've written several production apps (see Postach.io and QuoteRobot) in it and regularly use it for quick server scripts. Node.js wasn't actually my first choice, but I wanted something modern and designed for the new web. PHP, Python and Ruby are definitely not it. My first choice was to learn Go (golang) but time restrictions and the team skill-set didn't line up with that route. A startups gotta hustle you know! Node was a happy medium that we could get hacking on right away.

What are your thoughts on modern day languages? Do you still prefer Python or others? Why? Any Node "gotchas" you can share?

---

Need some help with your web or mobile app? The team and I at Input Logic would love to sit down and brainstorm some ideas.