# Kyle Elliott
> Notes on tech, trends, and whatever else catches my brain.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About this site
URL: https://blog.kyleelliott.net/about/
Last updated: 2025-06-04T19:12:54.000Z
Kyle Elliott Blog is an independent publication launched in June 2025 by Kyle Elliott. If you subscribe today, you'll get full access to the website as well as email newsletters about new content when it's available. Your subscription makes this site possible, and allows Kyle Elliott Blog to continue to exist. Thank you!
### Access all areas
By signing up, you'll get access to the full archive of everything that's been published before and everything that's still to come. Your very own private library.
### Fresh content, delivered
Stay up to date with new content sent straight to your inbox! No more worrying about whether you missed something because of a pesky algorithm or news feed.
### Meet people like you
Join a community of other subscribers who share the same interests.
---
### Start your own thing
Enjoying the experience? Get started for free and set up your very own subscription business using [Ghost](https://ghost.org/?ref=blog.kyleelliott.net), the same platform that powers this website.
### Privacy Policy
URL: https://blog.kyleelliott.net/privacy-policy/
Last updated: 2025-06-10T15:30:05.000Z
*We don’t collect personal data or use tracking cookies.*
## Posts
### The Hidden Cost of Letting AI Write Your Code
URL: https://blog.kyleelliott.net/the-hidden-cost-of-letting-ai-write-your-code/
Last updated: 2026-07-27T14:14:33.000Z
Everyone's shipping code faster now. AI writes it, a developer glances at it, it goes to QA (hopefully), then off to production. While this does sound efficient, it also sounds like a plan for problems you won't see coming until they're already live.
This is going to become the norm as companies lean into AI-generated code that without people that fully understand it driving the initiative.
## Security Is Only As Good As The Prompt
AI code generation tools are only as security-conscious as the person driving them. If you don't know what SQL injection is, you're not going to ask Claude to guard against it. If you don't know what a race condition looks like, you're not going to catch one in the output.
The AI isn't the problem, the gap in the prompt is the problem.
A developer who understands security asks specific questions: "sanitize this input," "use parameterized queries," "check for auth on this endpoint." A developer who doesn't know to ask just gets working code. Working code isn't the same as safe code. It just means it didn't crash on the happy path.
## You Really Need to Know Why
Here's a pattern that's becoming common: someone asks AI to write a feature, the code works, they ship it. Nobody asked the AI to explain what it did or why it did it that way.
Then something breaks in production. Now you've got a team staring at code nobody on the team actually understands. The code isn't bad so much as nobody knows the reasoning behind it.
This is a fixable habit. Ask for the explanation along with the code. "Walk me through why you structured it this way" takes ten extra seconds and saves you hours during an incident. Skip that step often enough, and you end up maintaining a codebase your own team can't explain.
If you're using Claude, use the Plan mode with reckless abandon. Sure it'll eat more tokens, but the overview of what it's going to do and why is extremely useful. I equate it to explaining what you need done to another developer and having them explain it back to make sure they understand the task. If you're not fully understanding what it's doing or it's helping you with a technology that is new to you take it a step further. Use the output from the planning session and ask for the 20% of the details that can help you understand 80% of the topic based off the plan and paste it in.
Photo by [Sebastian Herrmann](https://unsplash.com/@officestock?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## Use 'Em or Lose 'Em
Developers who lean on AI for everything stop practicing the fundamentals. Not out of laziness, but they lose the muscle memory.
Debugging is the clearest example. If AI writes the code and AI fixes the bugs, a developer never builds the instinct for spotting what's wrong just by reading. That instinct doesn't come from watching AI do it. It comes from doing it yourself, badly, a few hundred times.
Same goes for architecture decisions, for understanding tradeoffs, for knowing why one approach scales and another doesn't. Skip the reps, and the skill doesn't develop. It's not really different from any other skill you stop practicing.
## Junior Developers Won't Grow
Let's look further into the future for a minute... Junior developers learn by struggling through problems, getting it wrong, and figuring out why. That struggle is where the judgment comes from, the kind of judgment that eventually makes someone a senior developer.
If AI is doing the struggling for them, they're not building that judgment. They're producing output that looks like senior-level work (sometimes) without going through the process that actually makes someone senior.
Companies are going to feel this in a few years, not now. Right now it looks like productivity. Later it looks like a team full of people who can prompt well but can't reason through a novel problem when the AI doesn't have a clean answer for it.
## Where This Leaves You
None of this means that you shouldn't use AI to write code. It means treat it like you'd treat any tool that's powerful enough to hurt you if you don't know what you're doing.
Ask for the reasoning, not just the output. Keep your security knowledge current enough to know what to ask for. Run security audits against your systems. Make sure your junior developers are still doing hard things the hard way, at least some of the time. The speed is real. So is the bill, if you're not paying attention to what you're trading for it.
### Freelance Developer, Not Firefighter: Building Things That Don’t Break
URL: https://blog.kyleelliott.net/freelance-developer-not-firefighter-building-things-that-dont-break/
Last updated: 2026-05-08T13:07:57.000Z
When people talk about freelance development, they often focus on speed. Deliver fast, deliver now, move on. But the truth is, most of my work comes from the exact opposite problem: someone moved too fast, and now everything’s on fire.
Broken APIs, automation that silently fails, data that never makes it to the destination. Systems duct-taped together and barely holding. I’ve seen it across startups, internal tools, and even surprisingly large platforms.
Some clients come to me after that first fire. Others come after the fourth. By that point, it’s not just code that needs fixing. It’s trust, visibility, and process.
I’ve been doing backend and systems work long enough to know that you don’t prevent fires by coding faster. You prevent them by building with clarity and structure up front.
Here’s what that looks like in practice.
## **1\. Use Systems That Can Explain Themselves**
If someone can’t look at the workflow and understand what it does, it’s going to break at the worst possible time.
That’s why tools like Zapier, Make, n8n or Boomi make sense when used properly. Visual flow, sensible naming, and documented nodes go a long way. Even if I’m building something that “just works,” I want the next person to understand it without digging through a maze.
Every integration I build gets clear output handling, logging, and notes. Don't hide the complexity. It needs to be made legible.
Photo by [Yen Vu](https://unsplash.com/@yenvu2410?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
If you're writing code then you're going to want to document it well inside and out. Comments in the right places to explain code if it seems complicated, function explanations, class definitions, and a good README.md included with the source can make a substantial difference.
## **2\. Fail Loud, Not Silent**
Too many systems quietly fail when they hit bad data or a missing field. No alert, no retry, no visibility.
I try to set up failures to be obvious. If something goes wrong, someone gets a Slack message, an email, or a ticket in their system. Or at the very least, it logs somewhere that someone actually checks.
This isn’t complicated. You just have to care enough to wire in a fallback plan.
## **3\. Plan for Change, Not Just Launch**
Most systems don’t stay still. APIs change. Processes evolve. People leave. I have lost count of how many times I've asked who would know about the system only to be told the person who made it is no longer with the company and they left no documentation.
I build workflows and services with that in mind. That means versioned endpoints, loose coupling between systems, and environments that can be cloned or rebuilt without black magic.
For example, if I’m delivering an API, I’ll include a docker-compose file so they can spin it up anywhere. If I’m automating a workflow, I’ll include documentation that explains what triggers what, where secrets live, and how to test it without breaking production.
## **4\. Know When to Say “That’s Not a Good Idea”**
A big part of freelance work is being willing to push back.
I’ve had clients ask for solutions that seemed fast on the surface but would have turned into long-term maintenance headaches. Sometimes the fix isn’t writing code, but clarifying the real need and choosing the simpler path.
That’s part of the value I bring. It's a waste to build something when it isn't even needed in the first place.
## **What It Comes Down To**
I’m not in this to deliver something flashy and disappear. I’m here to help teams stop putting out the same fires every quarter.
That might mean building from scratch, or it might mean auditing and improving what’s already there. Either way, I approach projects with the same mindset: structure, reliability, and clarity.
It takes more effort up front, but it pays off every time something just works.
If you’re tired of building on sand and hoping nothing collapses, I’d be glad to help.
Let’s make something solid.
### What Even Is GraphQL, and Why Would You Use It Instead of REST?
URL: https://blog.kyleelliott.net/what-even-is-graphql-and-why-would-you-use-it-instead-of-rest/
Last updated: 2026-05-08T13:07:48.000Z
I’ve mostly worked with REST APIs over the years. They’re familiar, they’re everywhere, and they’re still the standard for most of the projects I touch. But lately, I’ve been seeing more jobs and clients asking for experience with GraphQL. So I spent some time digging in.
This isn’t a deep technical dive. It’s a practical overview of GraphQL and when it actually makes sense to reach for it, especially as a freelance developer.
## The Problem with REST (Sometimes)
REST works great in a lot of cases. You hit predictable endpoints and get back structured data. But there are a few common issues:
- **Overfetching**: You get more data than you need (e.g., a `/users` endpoint that returns everything).
- **Underfetching**: You have to make multiple requests to piece together what you actually want.
- **Rigid structure**: You’re stuck with what the endpoint gives you unless the API is updated.
In a small app, this doesn’t matter much. But when you’re working with complex data models (or trying to stitch systems together) it gets messy.
## What GraphQL Does Differently
With GraphQL, you describe **exactly** what data you need, and you get it in one request. It’s a single endpoint that takes a query payload.
```graphql
query {
user(id: 123) {
name
email
orders {
id
total
}
}
}
```
The response mirrors the query:
```
{
"data": {
"user": {
"name": "Kyle",
"email": "kyle@example.com",
"orders": [
{ "id": 1, "total": 49.99 },
{ "id": 2, "total": 23.75 }
]
}
}
}
```
You don’t need to hit three different endpoints or filter anything out on the client.
Photo by [Christopher Gower](https://unsplash.com/@cgower?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## **So, Why Would You Use GraphQL?**
Here’s where GraphQL starts to shine:
- **Frontend flexibility**: Frontend devs can ask for only what they need, no more, no less.
- **Reduced round-trips**: One call can replace several chained REST calls.
- **Strong typing**: Clients know what shape the data will be. That helps when working across teams or contracts.
## **Why You Might Not**
GraphQL is powerful, but it’s not always the best fit:
- **Overhead**: It takes more setup, especially if you’re building the schema yourself.
- **Caching is more difficult**: Since all requests go through the same endpoint, HTTP caching strategies don’t apply the same way.
- **Security and rate-limiting**: You need to be more careful about exposing data and controlling what can be queried.
## **My Take (So Far)**
If I’m spinning up a quick API or microservice for internal use, I’ll probably stick to REST. It’s easier to set up and reason through, plus more people understand it.
But if the project involves a growing frontend, complex relationships, or a need to reduce client-side logic, GraphQL is worth it. I’ve started using it more with automation tools too, since some APIs only expose GraphQL now.
I won't be replacing REST, but having another option when the use case fits.
*If you’ve been curious about GraphQL but put it off, give it an afternoon. Build something simple. Knowing when to use it is half the value anyway.*
### Why Discovery Is the Hardest and Most Overlooked Part of Large System Projects
URL: https://blog.kyleelliott.net/why-discovery-is-the-hardest-and-most-overlooked-part-of-large-system-projects/
Last updated: 2026-05-08T13:07:39.000Z
Most large projects don’t go off the rails because someone wrote bad code. They go off the rails because nobody really understood what they were changing in the first place.
When you’re updating a core business system or converting an ERP platform, discovery isn’t optional. It’s how you learn what you’re dealing with before making irreversible choices. But discovery is also the first thing cut when budgets tighten or deadlines loom. It’s “non-productive time.” It doesn’t look like progress.
The irony is that skipping it guarantees rework later. Every undocumented dependency, every unknown integration, every business rule that never made it into documentation becomes a future blocker. The hours saved up front multiply into weeks of delays later.
### **What Discovery Actually Is**
You need to document your current reality...
A proper discovery phase captures how things actually work today, not how we *think* they work. It’s a map of the current state, created before design or development begin. If the entire system vanished tomorrow, your discovery materials should be detailed enough to rebuild it from scratch.
Future-state design comes later. Discovery is about learning and documenting, not solving or rebuilding yet. It’s about asking the questions that surface the truth:
- What systems are in play?
- How do they talk to each other?
- Who uses them, and for what?
- What breaks if we touch this piece?
### **Why It’s Harder on Complex and Undocumented Systems**
In large enterprises, systems evolve faster than documentation. People move roles, integrations pile up, and business rules shift without anyone writing them down. Over time, the system that runs the business becomes half tribal knowledge and half mystery.
When those systems connect to large percentages of the business, even small unknowns can cause major ripple effects. You change one process and suddenly the warehouse stops syncing inventory, or the accounting rules no longer reconcile. None of it is intentional, but it’s what happens when the left hand doesn’t know what the right hand depends on.
Skipping discovery in this environment doesn’t just create rework. It introduces risk to the business itself. The cost of unplanned outages or data inconsistencies dwarfs whatever time was “saved.”
**What Good Discovery Looks Like**
A solid discovery phase is systematic:
**Break down each system.** Identify who owns it and how it fits into the bigger picture.
1. **Document it,** ideally by the people who actually work in it. External consultants can guide, but internal knowledge is critical.
2. **Map the integrations.** List every connection point, what data flows through it, and what triggers it.
3. **Talk to the business.** Processes and rules live in people’s heads as often as in the code.
4. **Get sign-offs.** Validation ensures everyone shares the same understanding.
5. **Identify risks early** and set a cut-off point for changes so the scope doesn’t keep expanding.
Photo by [Hai Nguyen](https://unsplash.com/@hai%5Fnguyen?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
The output of discovery should be something that gives leadership confidence and gives architects a solid foundation for design. It doesn’t need to be pretty; it needs to be accurate.
**The Architect’s Role**
During discovery, an architect’s job is to connect the dots. It’s the phase where you look across systems and spot the misalignments that could cause downstream failures. It’s where you ask, “If this system changes, what happens over there?” and make sure the answers are documented before any design begins.
Good architects understand that discovery is how you reduce the unknowns. The more complex the environment, the more critical that becomes. You can’t design cleanly around chaos.
**The Real Cost of Skipping Discovery**
When discovery is rushed, unknowns surface mid-project as blockers.
A missing integration. A legacy process no one mentioned. A dependency buried in a system nobody realized still mattered. Each one forces replanning, re-testing, and re-budgeting.
The project slows down, frustration builds, and the blame game begins. All because the team didn’t spend enough time learning what they were changing.
Every hour skipped in discovery comes back as days of rework. It’s one of the most predictable equations in project delivery.
**The Quiet Value of Clarity**
Discovery doesn’t get much credit. It doesn’t demo well. There’s no immediate payoff, just a pile of diagrams, notes, and process maps. But that quiet groundwork is what keeps the rest of the project from collapsing under its own weight.
Photo by [freestocks](https://unsplash.com/@freestocks?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
In complex systems, clarity is stability. Discovery gives you that clarity.
You can't think of it as moving slower, it’s about starting from a place where everyone actually knows what they’re building on top of. When you take the time to document what’s real, everything that follows becomes simpler, faster, and far less expensive. It generates less rework and missed requirements.
And if that sounds like overkill, just ask anyone who’s had to rebuild a system after skipping it.
### When the Architecture Isn’t Quite Right: Rethinking Solutions After Go-Live
URL: https://blog.kyleelliott.net/when-the-architecture-isnt-quite-right-rethinking-solutions-after-go-live/
Last updated: 2026-05-08T13:07:11.000Z
There’s a moment every architect eventually faces: the solution is live, users are in it, data is flowing… and something isn’t working the way it should.
Not because the team did anything wrong, but because reality finally showed you what the diagrams never could.
Sometimes an architecture looks elegant on paper/screen but behaves very differently under real load, real processes, and real business rhythms. And that’s normal. **Integration-heavy systems rarely reveal their true shape until they’re running.**
## **Why It Happens**
Pre-go-live, you’re working from assumptions: expected data volumes, expected usage patterns, expected system behavior. But assumptions behave beautifully while real systems do not.
A few things tend to surface after go-live:
- Message throughput is higher than planned
- A synchronous design starts causing bottlenecks
- A system behaves differently with live data than with test scenarios
- Errors scale faster than the error handling strategy
- Business rules show inconsistencies that weren’t obvious during discovery
- There wasn't an option for real-world test scenarios
Even with strong discovery, complex integrations don’t fully “show themselves” until everything is connected and living in the actual business workflow.
## **The Architecture You Designed vs. the Architecture You Need**
Sometimes the original design was good for what you knew. But once it hits production, you start to see where it needs to evolve. Perhaps your original process used point-to-point integrations because it seemed simpler, but now you’re seeing tight coupling causing cascading failures.
Maybe you used scheduled processes everywhere because the requirements seemed predictable, but now you’re seeing real-time needs appear or race conditions. Maybe you thought a single integration with branching logic would handle the workflow well enough, and now it’s slowing down or becoming difficult to troubleshoot.
Try not to think of these situations as failure. This is what *real* architecture looks like: the willingness to reassess and adapt once truth replaces assumptions. Iteration is key.
## **When the Right Move Is a Modern Pattern**
A lot of re-architecture moments come down to one thing: **The system needs to decouple.** That often means introducing technologies or patterns like:
- **Message Queues**
- **Pub/Sub**
It’s extremely common to start with simple integration calling APIs directly, only to realize later that introducing messaging in the middle creates far more stability.
**Workflow Separation**
Sometimes the re-architecture is simply splitting a process into smaller, clearer pipelines. Low-code/no-code single-process designs can get bulky fast. Breaking them into distinct, event-driven flows often simplifies maintenance and improves visibility and ease of troubleshooting.
Photo by [Jakub Żerdzicki](https://unsplash.com/@jakubzerdzicki?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## **The Emotional Side Nobody Talks About**
It’s easy to feel like rearchitecting after go-live means the first design was wrong. Usually, it just means the system finally showed what it really needed. Architecture isn’t fortune-telling. It’s hypothesis → implementation → observation → adaptation. That last step is where a lot of systems fall apart because teams are afraid to admit the design needs to evolve.
You don’t fix what was “wrong.” You refine based on the *current reality* with information and benchmarks you may not have had available when the design phase was active.
## **Signs It’s Time to Rearchitect**
You’ll know it’s time to evolve the design when you see things like:
- Frequent retries or timeouts
- Processes backing up cause data to move too slowly
- Overwhelmed downstream systems
- Off-peak jobs creeping later and later
- Support needing more visibility or traceability
- Business teams reporting inconsistent outputs
- “Quick fixes” piling up on top of each other
When these checkboxes start to fill up you know it's time to begin iterating.
## **Moving Forward Without Blame**
Re-architecture shouldn’t be treated as an admission of a bad plan. It should be treated the same way you treat iterative development: a natural next step as more information comes to light.
The important part is *how* you approach it:
- Document what the reality looks like now
- Identify where coupling or bottlenecks appear
- Introduce patterns that give flexibility, not rigidity
- Think long-term instead of patchwork
- Communicate the why, not just the what
- Keep scalability in mind
Good architecture evolves. Stagnant architecture ages and falls apart over time.
---
Every architect eventually learns that the real architecture of a system emerges only once it’s lived in. What you design before go-live is your best educated guess. What you redesign afterward is more informed and better for the long-term.
The important thing is that you keep learning from the system instead of forcing it to match a diagram that never had the full picture. As your experience grows you'll be able to get closer to the real thing on the first try, but it's rare to nail it the first time.
### The AI Homeschool Principal: How I Built a System That Plans My Daughter's Entire School Week
URL: https://blog.kyleelliott.net/the-ai-homeschool-principal-how-i-built-a-system-that-plans-my-daughters-entire-school-week/
Last updated: 2026-05-07T13:05:10.000Z
Homeschooling a high schooler is a lot. There's curriculum planning, assignment creation, grading, record-keeping, and the constant challenge of keeping a teenager engaged with material that actually interests her. I'm a tech person by trade, so naturally I asked myself: what if I could automate the boring parts?
The result is what I've started calling my **AI Homeschool Principal** which serves as an automated pipeline that plans weekly assignments and reviews submitted work, all without me having to micromanage every step.
## The Problem I Was Solving
My daughter is 15\. She's sharp, but like most teenagers, she tunes out fast if the material feels generic or disconnected from things she actually cares about. And on my end, the overhead of planning a week of assignments across multiple subjects, making sure it aligns with state requirements, and then reviewing everything she turns in, well... it was a lot more time than I anticipated.
I didn't want a curriculum app or a tutoring platform. I wanted something I could tailor completely to her. Something that could match her pace, her interests, and the state's specific guidelines.
## How It Works (Without Getting Too Deep in the Weeds)
The system is built on a handful of tools I already use and trust: **n8n** for automation workflows, **Google Gemini** as the AI brain, **PostgreSQL** for structured data, **Google Drive** for file storage, **Telegram** for notifications, and **Tavily** for web search when the AI needs current information. It all runs in **Docker** on my home server.
Here's the basic flow:
**1\. The curriculum is already mapped out.** Using Gemini and the state reference material I created a high-level lesson plan for each week. From there I made modifications by hand to adjust for learning differences, weeks off, 504 plan adjustments, etc. From there I can insert that data into a database table so I have the pre-planned the academic year week by week; subjects, topics, pacing. Using a mix of AI and manual intervention once I can make sure it's solid. Any mid-year adjustments can be made directly in the table.
**2\. Every week, the system generates assignments automatically.** At the start of each week, n8n triggers a workflow that pulls the current week's topics from the database, feeds them to Gemini along with our state's curriculum standards and homeschool laws, and generates a full assignment list. Additionally, it also pulls from a list of my daughter's interests and hobbies, so the AI finds ways to frame the work around things she actually cares about. History through the lens of something she's into. Writing prompts that connect to her world. It makes a genuine difference in engagement.
**3\. She submits her work to Google Drive.** Nothing fancy here. Each week has a folder. Each day of that week has a folder. At the end of the week each folder will have that day's assignment list and several docs and files representing her completed work ("English Assignment", "Science Assignment", etc.).
**4\. At the end of the week, the system reviews everything.** Another n8n workflow picks up the submitted work, sends it through Gemini for review against the assignment criteria, and produces feedback. The feedback is aggregated into a single Google Doc that gets dropped in the weekly folder before I get a summary via Telegram with a link to the feedback Doc.
Photo by [jose aljovin](https://unsplash.com/@josealjovin?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## What I've Learned So Far
The interest-based personalization is the feature I underestimated most. I thought it would be a nice-to-have, but it turned out to be the thing that makes the system actually work day-to-day. When assignments connect to things she's genuinely curious about, she engages differently.
The state standards integration also took more upfront effort than I expected, but it was worth it. Most of that work was getting around some quirks with how Gemini worked with N8N and Postgres vector store. However, knowing the system is generating work that maps to real requirements removes a layer of anxiety from the whole homeschool experience.
It's not perfect. AI-generated assignments still need a human eye occasionally. And the review/grading side is more "structured feedback" than true assessment. I'm still involved in the final evaluation. I still enjoy reading her work so I'm usually in there a couple of times a week doing manual review with the context of the AI feedback in mind. However, the time savings are significant, and the consistency is something I couldn't have maintained manually.
## Reporting
Each quarter a template is used to generate quarterly reports that are dropped into a specific folder for review. Once I'm good with the output I can submit them to the state.
## Cost
Now how much does all of this cost? I'm paying under $20/month for the VPS, could be even less, but I'm using it for a lot of other things besides this setup. Gemini token, using the lighter models, is typically less than $0.50 per week. As of now, even with testing and it running for a couple of weeks, I haven't even hit $1 in spend.
> Pro Tip: Always set a max monthly spend. Too often to read about rogue processes racking up a huge bill.
## Is This For Everyone?
Probably not in this form. Building this required comfort with automation tools, APIs, and a bit of systems thinking. But the underlying concept of using AI to handle the repetitive planning and review work of homeschooling is accessible even without a custom build. Tools are getting good enough that you don't need to roll your own. Even with this approach, some technical knowledge is needed. Especially when working with the AI itself to get expected outputs and how to use the tools with the agents.
What I do think translates universally: **the value of personalizing curriculum to the student, not the other way around.** Whether you're building a pipeline like mine or just using an AI assistant to help with lesson planning, that principle is worth centering.
I'll be writing more about the technical side of this build in future posts. If you're a homeschool parent curious about the concept, or a developer who wants to build something similar, feel free to reach out.
### Self-Hosting a Matrix Server: What Actually Worked
URL: https://blog.kyleelliott.net/self-hosting-a-matrix-server-what-actually-worked/
Last updated: 2026-02-24T16:41:00.000Z
I recently set up a private Matrix server on a 4GB VPS for my family. Not because I enjoy pain, but because I wanted a self-hosted alternative. So many platforms are asking for too much personal information. Then storing that information in an insecure fashion and it ends up being leaked (I'm looking at you Discord).
Though not specifically related; when Google shut off API access to the Nest thermostat that I paid for it made me realize that platform dependency sucks. Since I have the ability I wanted to try self-hosting more systems in my day to day.
## The Stack
The core is **Synapse** (the Matrix reference homeserver) running behind **Caddy** as a reverse proxy, all wired together with Docker Compose. I also added a **Synapse Admin** container for GUI-based user management.
Coturn and Livekit for voice and video calling as well as the Livekit JWT service.
Caddy was the right call for the reverse proxy. It handles SSL certificates for your domain automatically; no Certbot configuration, no cron jobs. You point it at a domain and it figures out the rest.
The Synapse Admin UI sits at under 30MB of RAM, which on a 8GB VPS is practically free. It means I can reset passwords, manage users, and deactivate accounts without touching the terminal every time.
I can run all this alongside my existing portfolio, blog, and N8N systems with room to spare.
Photo by [Shubham Dhage](https://unsplash.com/@shubhudi?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## Federation
Federation lets your server talk to the wider Matrix network — so your users can join rooms on `matrix.org` or message people on other homeservers. Getting this working required adding `.well-known` headers in the Caddyfile so other servers could find mine correctly.
One thing to know: joining a large public room for the first time kicks off a **State Resolution** process. For a smaller VPS, this can spike CPU and RAM hard enough to cause real problems. Join big rooms one at a time. Give the server time to settle before adding another.
## Getting the First Admin
This is the part that catches everyone. The Synapse Admin API requires an admin user to authenticate — but you can't promote a user to admin through the API until you already have one. Classic chicken-and-egg.
Two reliable paths out of that loop:
1. **`register_new_matrix_user`** — a CLI script included with Synapse that can create an admin user directly.
2. **Direct SQLite update** — modify the database on the mapped volume from the VPS host.
Important: modern Synapse Docker images are distroless. There's no `sqlite3` or `curl` inside the container. Run all database operations from the host machine using the mapped volume path.
After promoting a user via the database, don't expect it to work immediately. **You have to log out and back in.** The active session holds an old access token that doesn't reflect the new permissions. I wasted a while on this one.
Also: Matrix user IDs are **case-sensitive in the database**. If you run a SQL update with the wrong casing, it silently updates zero rows. Double-check the exact username as it appears in the registration record.
Photo by [Sasun Bughdaryan](https://unsplash.com/@sasun1990?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
## Keeping It Private
Synapse has an option for **registration tokens** — you generate a token, share the link with family, and anyone without it can't create an account. The server stays closed to the public without completely disabling registration. Disabling public registration keeps folks out that you would potentially need to verify yourself should the laws change.
## Performance Tuning
One config change made a noticeable difference: disabling global presence.
```yaml
use_presence: false
```
When you federate with large servers, presence tracking (knowing who's online/offline) generates a constant stream of traffic. Turning it off cuts a significant chunk of idle workload. For a small private server where everyone knows each other anyway, it's an easy trade.
## Nuance
When setting up the voice/video calls make sure you pay attention to the tokens that go between the JWT Livekit service, Livekit, and the homeserver.yaml files. That tripped me up more than once.
## Quick Reference: Gotchas
| Issue | | What to do |
| ---------------------------------------- | | ------------------------------------------- |
| Admin API not working after DB promotion | | Log out and back in to get a fresh token |
| sqlite3 not found in container | | Run from VPS host using mapped volume |
| SQL update affected 0 rows | | Check username casing — it's case-sensitive |
| CPU spike joining a room | | Join large rooms one at a time |
| High idle load from federation | | Set use\_presence: false in config |
---
This setup has been running cleanly since I got it sorted. My friends that have used it say that the voice chat quality is just as good as Discord's. Video chat works fine as well. If you're standing up something similar and hit a wall, feel free to drop a comment below.
Hopefully I won't regret all this later.
### From Overwhelmed to In Control: Taming IT Industry Chaos with Simple Automation Rituals
URL: https://blog.kyleelliott.net/from-overwhelmed-to-in-control-taming-it-industry-chaos-with-simple-automation-rituals/
Last updated: 2025-09-03T12:00:25.000Z
If you work in IT, you know the chaos: constant fire drills, endless emails, unpredictable bugs, and the never-ending sprint to keep things running smoothly. The IT world moves fast, and trying to keep up manually is like trying to herd cats while juggling flaming torches. It’s exhausting and usually ends with burned fingers.
But what if you could get ahead of this madness? What if, instead of drowning in tasks, you had a few simple automation rituals that help you take back control. Doing so without turning your life into a complex coding project or requiring a PhD in robotics?
# Why Automation, and Why Now?
Automation isn’t just for the tech giants or super-nerds with unlimited time and resources. Thanks to intuitive, no-code and low-code platforms, automation is now accessible for anyone willing to invest a little time upfront. These tools let you build quick workflows that save hours every week by cutting out repetitive manual tasks. For example:
- Automatically sorting and saving email attachments to the right folder.
- Generating routine reports with a click instead of an all-day affair.
- Setting up alerts for critical system events that actually get your attention.
It’s about creating habits. Those small, reliable rituals that keep the chaos from spiraling out of control.
# Simple Rituals That Make a Big Difference
Here are some automation rituals that you can actually stick with:
1. **Morning Inbox Zero with Automated Filters:** Use rules to tag, categorize, or archive emails automatically. Your morning starts with only what truly needs your attention.
2. **Automated Daily Status Updates:** Set up a lightweight system. It can be Slack bots, email digests, or something that collects and sends brief updates. No more hunting for progress across multiple tools.
3. **Routine Maintenance Scripts:** Schedule scripts that handle backups, system updates, or log cleanups overnight, so you don’t have to manually micromanage.
4. **Integration with Calendar and Task Tools:** Trigger reminders, deadlines, and follow-ups automatically synced across your devices to keep nothing slipping through the cracks.
Implementing these rituals is less about perfection and more about momentum. You’re not building a spaceship; you’re installing a set of guardrails.
# The Payoff: Less Chaos, More Focus
When automation handles the grunt work, you free up mental bandwidth to focus on what really matters: designing better systems, solving complex problems, and maybe even taking a breath once in a while.
The beauty? Automation isn’t static. Start simple, see what saves you time, and iterate. Over time, these rituals add up, transforming your workday from a chaotic scramble into a manageable flow.
### Why APIs Fail in Real Life: A Field Guide for Architects
URL: https://blog.kyleelliott.net/why-apis-fail-in-real-life-a-field-guide-for-architects/
Last updated: 2025-08-19T12:01:22.000Z
Sometims APIs fail. It can be code bugs or server crashes. It can also be a messy mix of design choices, real-world chaos, and sometimes, plain old human error. Here some areas for architects to watch out for.
**1\. Ignoring the User’s Perspective**
APIs are for people (and their apps), not just for machines. Design with your consumers in mind. If they can’t figure out how to use it easily you can say goodbye to adoption.
**2\. Skimping on Error Handling**
Fail gracefully. When your API breaks, provide meaningful error messages, not just cryptic '500 Internal Server Error' nonsense. Good error feedback is your best debugging pal.
**3\. Lack of Versioning**
Change is inevitable. Not versioning your API means you risk breaking existing clients when you update. Version early, version often. Make the supported version history clear so consumers know when they need to start moving to a new version.
**4\. Overcomplicating Endpoints and Payloads**
Keep it simple. Overloaded APIs become fragile and hard to maintain. Streamlined, focused endpoints save headaches down the road.
**5\. Security Slip-Ups**
APIs often expose critical business logic and data. Don’t treat security as an afterthought. Token expiration issues or misconfigured permissions can cause cascading failures.
**Bonus: Not Planning for Failures**
Expect problems. Servers crash and networks drop. Build fallback and retry logic into your architecture from day one to keep your system resilient.
In the end, a great API is less about perfect tech and more about thoughtful design and real-world practicality. So next time your API misbehaves, check the basics before blaming the cloud gods.
### Why ‘No-Code’ Isn’t a Shortcut, It’s a Skill for Tomorrow’s Devs
URL: https://blog.kyleelliott.net/why-no-code-isnt-a-shortcut-its-a-skill-for-tomorrows-devs/
Last updated: 2025-08-13T12:01:20.000Z
### Preparing for Tomorrow’s Tech Landscape
The future isn’t about hand-crafting every line of code; it’s about orchestrating services, automations, and workflows faster than ever. No-code skills give you the edge to innovate in this fast-paced environment. And if you have ADHD or juggle a thousand ideas at once like me, no-code can be a sanity-saving way to turn thoughts into functioning prototypes without banging your head against syntax for hours.
### Bottom Line
No-code isn’t a shortcut that skips the hard parts of software development. It’s a **different set of muscles**, one that’s aligned with tomorrow’s demands for speed, flexibility, and big-picture thinking. So if you’re a dev or aspiring dev, get curious. Dive in. It’s not about cutting corners; it’s about building smarter.
### Regular People Using AI
URL: https://blog.kyleelliott.net/regular-people-using-ai-2/
Last updated: 2025-08-07T19:30:07.000Z
Draft
**The Micro-Tools That Saved My Freelance Sanity (And Clients Loved Them)**
Freelancing is a wild ride — the tightrope walk between juggling multiple projects, keeping clients happy, and not losing your damn mind. Over time, I stumbled upon a few micro-tools that didn’t just keep me afloat but made my workflow smoother and clients happier.
Here’s a quick rundown of the little lifesavers that made a big difference:
- **Trello**: For a simple, visual way to track progress without drowning in emails. Boards for each client, cards for tasks, and boom — clarity!
- **Calendly**: Ditch the back-and-forth in scheduling meetings. Clients book what works for me, no awkward email chains.
- **Grammarly**: Because nobody wants to send out sloppy emails or work. A quick grammar check saves me from embarrassing typos.
- **Loom**: When words fail or explanations get long-winded, a quick video walkthrough makes everything 10x easier for clients.
- **Wave Accounting**: Free, straightforward invoicing and bookkeeping without the headache of complex software.
These aren’t shiny, complex systems, rather small tools that cut the noise and let me focus on the work that matters. Clients notice the difference when communication is clear, deadlines are met, and billing isn’t a pain.
If you’re freelancing and feel overwhelmed, try a couple of micro-tools. They might just save your sanity like they did for me.
### Regular People Using AI
URL: https://blog.kyleelliott.net/regular-people-using-ai/
Last updated: 2025-08-07T19:28:55.000Z
Draft
**The Micro-Tools That Saved My Freelance Sanity (And Clients Loved Them)**
Freelancing is a wild ride — the tightrope walk between juggling multiple projects, keeping clients happy, and not losing your damn mind. Over time, I stumbled upon a few micro-tools that didn’t just keep me afloat but made my workflow smoother and clients happier.
Here’s a quick rundown of the little lifesavers that made a big difference:
- **Trello**: For a simple, visual way to track progress without drowning in emails. Boards for each client, cards for tasks, and boom — clarity!
- **Calendly**: Ditch the back-and-forth in scheduling meetings. Clients book what works for me, no awkward email chains.
- **Grammarly**: Because nobody wants to send out sloppy emails or work. A quick grammar check saves me from embarrassing typos.
- **Loom**: When words fail or explanations get long-winded, a quick video walkthrough makes everything 10x easier for clients.
- **Wave Accounting**: Free, straightforward invoicing and bookkeeping without the headache of complex software.
These aren’t shiny, complex systems, rather small tools that cut the noise and let me focus on the work that matters. Clients notice the difference when communication is clear, deadlines are met, and billing isn’t a pain.
If you’re freelancing and feel overwhelmed, try a couple of micro-tools. They might just save your sanity like they did for me.
### Sometimes Paper Works Better
URL: https://blog.kyleelliott.net/sometimes-paper-works-better/
Last updated: 2025-08-07T13:33:40.000Z
In a world obsessed with all things digital, it’s tempting to believe that paper is passé. But let’s be honest, sometimes paper just works better.
Think about it. When you’re in a meeting, pulling out a laptop or phone can look like you’re checking emails or scrolling anything else. Meanwhile, a simple notebook and pen quietly signal you’re all in. Plus, jotting down notes by hand helps most of us retain info way better than typing ever could.
There’s also the sheer flexibility of paper. Sticky notes can adorn desks, monitors, or walls without any app or battery. Sketching a quick diagram or brainstorming flow on paper often feels faster and more natural than fiddling with a digital tool. Full control over the layout helps too.
Don’t get me wrong, I love my apps and cloud docs. But tech isn’t a one-size-fits-all solution. Sometimes the quick, low-tech fix is the best route: no distractions, no loading times, no 'where did that file go?' moments.
The real magic happens when you blend both worlds. Leveraging paper’s tactile ease and digital’s power and accessibility. A scanned note can live forever in the cloud; a handwritten brainstorm can spark ideas you never expected. If you transfer your analog notes to digital it also helps to distill
So next time you’re tempted to go full digital, consider reaching for a notebook instead. Sometimes, the old-school way is exactly what your brain, and your workflow, needs.
### The Micro-Tools That Saved My Freelance Sanity (And Clients Loved Them)
URL: https://blog.kyleelliott.net/the-micro-tools-that-saved-my-freelance-sanity-and-clients-loved-them/
Last updated: 2025-07-30T12:00:09.000Z
The Micro-Tools That Saved My Freelance Sanity (And Clients Loved Them)
Freelancing is a wild ride. The tightrope walk between juggling multiple projects, keeping clients happy, and not losing your damn mind. Over time, I stumbled on a few micro-tools that didn’t just keep me afloat, they straight-up upgraded my workflow and made clients go, “Wait, how are you so on top of everything?”
Here’s a quick rundown of the little lifesavers that made a big difference:
Notion: My second brain. Client docs, project specs, reusable content blocks; all in one place. If it’s not in Notion, it doesn’t exist.
Todoist: Simple, clean task tracking that doesn’t try to do too much. Just enough structure to keep me from missing deadlines, but not so rigid I hate using it.
n8n: The automation glue holding my chaos together. From auto-tagging leads to sending reminders and syncing Notion pages, it runs the backstage magic so I don’t have to.
These aren’t flashy, complicated systems, rather quiet little tools that cut through the noise and let me focus on the work that matters. Clients notice when things run smooth: deadlines hit, updates land when expected, and nothing falls through the cracks.
If you’re freelancing and feel like you’re constantly playing catch-up, try a couple of micro-tools. They might just buy you back some peace of mind (and maybe even your weekends).
### Importance of Guardrails for AI
URL: https://blog.kyleelliott.net/importance-of-guardrails-for-ai/
Last updated: 2025-07-29T12:00:58.000Z
We’re all riding the AI wave right now and yeah, it’s impressive. Automation is faster. Content is quicker. Tools are multiplying like rabbits. But here’s the thing nobody likes to talk about: without guardrails, AI becomes less of a superpower and more of a liability.
It’s the digital equivalent of giving a toddler a chainsaw. Sure, they could be productive. But without structure? Chaos.
Why Guardrails Matter
AI models, especially generative ones, are creative, but they’re not wise. They’ll happily hallucinate facts, reinforce bias, or offer up “solutions” that violate compliance standards or just plain common sense. Guardrails are essential. Here’s why:
Accuracy & Reliability: No one wants a chatbot confidently spitting out made-up data. Guardrails help filter the nonsense.
Ethical Boundaries: AI doesn’t know your company’s values unless you tell it. Guardrails encode what “right” looks like.
Workflow Integrity: Automations without constraints break things. Guardrails make sure your AI fits into your process, not the other way around.
Brand Voice & Tone: Left alone, AI will sound like a weirdly enthusiastic intern. Guardrails ensure consistency and professionalism.
Good Guardrails Aren’t Shackles
This isn’t about limiting creativity. Guardrails guide AI toward more useful, responsible output. Think structured prompts, contextual memory, approval workflows, data boundaries. It’s the difference between a brainstorm and a brand risk.
In my own automations, I’ve started building in sanity checks and pre-set parameters. Whether it’s for Notion content summaries, lead generation flows, or AI-assisted draft. It’s not about control for control’s sake. It’s about trust.
Guardrails Can Be Tech or Team
Tech Examples: Prompt templates, system message injection, model fine-tuning, sandboxed environments, or filtering output through external validation tools (even regex rules can help).
Team Practices: Review steps, usage policies, defined roles for when AI suggestions are auto-approved vs. require human judgment.
Even in low-code or no-code tools, this mindset matters. Build like your AI is helpful… but kind of a chaos goblin. Assume good intent, but verify.
API & System Access Matters Too
One of the most overlooked guardrails? Limiting what your AI can touch. If your AI agents can write to production systems, trigger workflows, or access sensitive APIs without restriction, you’re asking for trouble. Use scoped API keys, role-based access controls, and sandboxed environments to ensure your AI doesn’t accidentally (or confidently) delete the wrong database or email your client list at 3AM. Guardrails help to define access so your entire code repo doesn’t get deleted by your AI assistant.
Final Thought
Unbounded AI might seem exciting, but smart constraints are what make it actually useful. Guardrails give us confidence. They reduce risk. And they let us go faster, not because we trust the AI blindly, but because we’ve done the work to make it safe.
If you’re building with AI, your first prompt shouldn’t be “What can it do?” It should be, “What should it never do?”
### Could AI hype become circle back around to full rejection?
URL: https://blog.kyleelliott.net/could-ai-hype-become-circle-back-around-to-full-rejection/
Last updated: 2025-07-22T18:35:40.000Z
Could AI hype become a circle back around to full rejection? It’s a question that’s quietly bubbling under the surface as the AI frenzy hits what some call the 'trough of disillusionment.' We’ve been here before with tech; think blockchain, the dot-com boom. Even AI winters of the past where expectations balloon, then reality bites, and the hype deflates, sometimes hard.
Right now, generative AI dazzles with promise and panic in equal measure. But history and recent signals suggest that after the hype peaks, skepticism often swings the pendulum too far the other way. Gartner’s hype cycle shows us this pattern: inflated expectations, crash, then eventual steady progress. So, could the pendulum swing from hype to outright rejection? Sure. But it’s unlikely to stick.
The key difference today is that AI is deeply embedded in tools and workflows already. Businesses and developers aren’t ready to throw the baby out with the bathwater. Instead, many are bracing for a more realistic, nuanced phase. It’s less about rejecting AI and more about cutting through the noise, sorting hype from real capability, and figuring out how to work with AI sensibly.
In short: a full rejection seems unlikely, but a healthy dose of skepticism? Absolutely. The AI hype bubble deflating is less a death knell and more of a maturity marker. The technology, like any, will find its real place; just probably not the sci-fi utopia or dystopia headline writers want.
Companies and individuals are still trying to fund the best uses of AI and the tools that use it.
If you’re feeling whiplash from the hype cycle, you’re not alone. The smart move is to stay curious, stay skeptical, and keep watching where AI can genuinely add value without losing your mind in the buzz.
What’s your take? Are we really heading towards full AI rejection, or just the calm after the storm?
### The Emotional Toll of Over-Automating (And How I Learned to Stop)
URL: https://blog.kyleelliott.net/the-emotional-toll-of-over-automating-and-how-i-learned-to-stop/
Last updated: 2025-07-17T12:00:53.000Z
Over-automating tasks at work might sound like a dream. Less busywork, more efficiency; but the emotional toll can sneak up on you. I found myself drowning in automated alerts, endless integrations, and workflows that worked *too* well. Instead of freeing me up, they stressed me out. Here’s the thing: automation can reduce repetitive tasks, but too much strips away the human touch and creativity. It can even increase anxiety and burnout, as studies from places like the University of Wolverhampton and research on workplace AI effects reveal that people working with machines often experience negative mental health impacts and chronic boredom. They also can lose their critical thinking and execution skills.
So how did I learn to stop over-automating? I started asking myself: ？ Does this automation actually *help* or just complicate?
？ Am I losing sight of the human element and the bigger picture?
？ Is it saving time or just shifting the burden elsewhere?
I pared back the robotic processes, keeping only what truly added value. I gave myself permission to do some things manually. I felt more in control, less anxious, and yes, even more creative. Automation should be a tool, not a trap.
If you’re drowning in bots and scripts, remember that sometimes doing less automation is actually more. Your mental health will thank you.
What’s your experience with automation burnout? Drop a comment. Let’s figure out the balance together. 🔥
# Automation #MentalHealth #Productivity #WorkLifeBalance
### What I Learned From Migrating an Entire Workflow Off Airtable
URL: https://blog.kyleelliott.net/what-i-learned-from-migrating-an-entire-workflow-off-airtable/
Last updated: 2025-07-15T12:36:33.000Z
Migrating an entire workflow off Airtable was a bit of a reality check. Airtable’s great: flexible, easy-to-use, and packed with features that let you build custom database-powered workflows without turning into a full-time dev. But when your needs start to outgrow its limits, or turns out it wasn’t the correct solution in the first place, you realize it’s not all sunshine and rainbows.
Here are some hard-earned lessons:
1. **Know What You Really Need**
Airtable’s charm is in its versatility. But that versatility can become a trap if you haven’t nailed down the core workflows that matter most. Migrating everything at once isn’t the way to go. Prioritize critical workflows and move them last.
2. **Feature Gaps Bite**
Airtable’s unique features like formula fields and easy views don’t always translate to other tools. You’ll need to rethink or rebuild those features, which can be a headache. Expect some compromises.
3. **Data Cleanup is Mandatory**
Your Airtable bases might be messy, with inconsistent data and legacy cruft. Use migration as a chance to clean house. It saves headaches in the long run and makes your new setup way more reliable.
4. **Automations Can Be a Bottleneck**
Airtable automations are handy but limited. When they max out or break, your workflow stalls. Moving off means designing smarter, scalable automation workflows, possibly using dedicated tools.
5. **Expect a Learning Curve**
Switching platforms shakes up habits. Your team will need time and training to adjust. Be patient and document everything well.
In the end, moving off Airtable is less about abandoning a tool and more about evolving your process. It forces clarity, prioritization, and smarter tech choices. If you’re facing similar growing pains, don’t fear the move; just plan it right.
### Why ‘Good Enough’ Automation Beats Perfect Every Time
URL: https://blog.kyleelliott.net/why-good-enough-automation-beats-perfect-every-time/
Last updated: 2025-07-09T12:25:21.000Z
In the quest for automation, perfection can be the enemy of progress. The truth? A **‘good enough’ automation solution often delivers more business value than a perfect one stuck in development hell**.
Here’s why settling for good enough can beat perfect every time:
1. **Speed to value**: Shipping a solution that covers 80% of functionality means you start reaping benefits sooner. Waiting for every edge case to be automated perfectly delays impact, and no one’s getting paid to wait.
2. **Iterative improvement**: ‘Good enough’ automation can be refined continuously. Launch early, learn from real-world usage, and improve. Perfection up front ignores feedback loops and evolving needs.
3. **Cost-effectiveness**: Perfect solutions require huge upfront investments on time, money, and brainpower. Good enough balances investment with return, maximizing ROI without wasting resources chasing flawless.
4. **Focus on impactful automation**: Automate where it counts, not where it’s just nice to have. Attempting to automate every last detail can introduce complexity, bugs, and maintenance headaches.
5. **Better decision-making velocity**: Real-time automation, even if imperfect, accelerates decisions and processes. In fast-paced environments, *faster* beats *flawless*.
The takeaway? **Aim for automation that’s reliable and delivers real business impact; not the unicorn of perfect, bug-free automation.** Get it out there, then iterate.
Automation isn’t about perfection. It’s about momentum.
### Measuring AI Productivity Gains
URL: https://blog.kyleelliott.net/measuring-ai-productivity-gains/
Last updated: 2025-07-08T17:57:19.000Z
**Measuring AI Productivity Gains: What Actually Moves the Needle?**
We all hear the hype about AI boosting productivity, but how do you *measure* that? Throwing AI at a problem doesn’t automatically mean you get more done or better results. It’s about digging into the details.
### Where to Start: The Metrics That Matter
Experts recommend focusing on a few key areas to quantify AI’s impact:
- **Worker productivity**: Are tasks completed faster? Is there less effort involved? Look at things like quicker issue resolution, smoother collaboration, and fewer process bottlenecks.
- **Output quality**: Not just more work, but *better* work — fewer errors, higher accuracy, improved customer satisfaction.
- **Time savings**: How many hours are freed up because AI automated or sped up parts of the workflow?
For example, studies show customer support agents guided by AI can boost productivity by nearly 14%, and in some software development cases, generative AI can improve coding speed by 20-40%!
Person holding a gear and other imagery representing ideas.
### The Challenges: It’s Not Just a Numbers Game
Measuring AI gains isn’t as simple as stopwatch + output. Context matters; the same AI tool might revolutionize one team’s workflow but barely move the needle for another. You need context-specific KPIs and a baseline control group to compare against.
Plus, productivity isn’t just quantity. Sometimes AI frees up people to focus on more creative or strategic work. This is harder to measure but still a win.
### Practical Tips for Your AI Productivity Scorecard
- **Pick role-specific KPIs:** For marketers, it might be content volume and engagement; for devs, lines of code or bug fixes.
- **Combine quantitative and qualitative data:** Numbers give you scale, feedback gives you color.
### Final Thought
AI’s productivity gains are real, but measuring them demands nuance and patience. Start with clear metrics, keep the human factor front and center, and remember — it’s not magic, it’s a tool to make work better and smarter.
### How Gaming Sharpened My Software Architecture Skills (No Joke)
URL: https://blog.kyleelliott.net/how-gaming-sharpened-my-software-architecture-skills-no-joke/
Last updated: 2025-07-01T12:00:39.000Z
**When I say gaming helped me sharpen my software architecture skills, I’m not just talking about the usual "gaming makes you better at problem-solving" cliché.**
Over the years, I’ve realized that diving into video games, especially the ones with complex systems and strategic depth, was secretly giving me a crash course in software architecture. Here’s how:
### 1\. Thinking in Systems and Layers
Games, especially strategy or simulation games, are basically layered systems working together. You have resource management, unit controls, AI behavior, UI updates, and more. They force you to *think about how different components interact* without becoming a tangled mess. Translating that to software, it’s the same principle as breaking down a monolith into micro-services or modular components. Gaming honed my mental model of abstraction, separation of concerns, and encapsulation long before I heard those buzzwords in meetings.
### 2\. Embracing Complexity and Trade-offs
Great games balance complexity with clarity. If a game’s mechanics are too convoluted, players (including me) bail. The same goes for software. Gaming trained me to recognize when a feature or system was becoming too complex and to think about trade-offs between performance, maintainability, and user experience. It’s a kind of *soft skill* that’s invaluable for architects.
### 3\. Iteration and Refactoring in Real-Time
Ever played a game where you tweak your strategy constantly? That’s iteration in action. In software architecture, you’re never done. You refactor, adjust, and optimize. Games teach you to be comfortable with experimentation and continuous improvement instead of 'getting it perfect on the first try.'
Photo by [Kristina Tochilko](https://unsplash.com/@tochilko?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
### 4\. Debugging Under Pressure
Gaming has a way of throwing curveballs; bugs, unexpected AI behaviors, or timing issues. Tracing down problems in a game environment feels a lot like debugging complex software systems, sharpening my problem-solving skills under pressure.
### 5\. Collaboration and Communication
Multiplayer games taught me the importance of clear communication and teamwork. Skills every architect needs. Whether it’s coordinating with devs, stakeholders, or designers, clear storytelling and documentation are key. Gaming’s cooperative aspect helps with that.
---
Gaming isn't just a fun distraction; it's a powerful, unconventional teacher. If you’re a software architect or developer, maybe it’s time to dust off that controller or keyboard and take a fresh look at gaming through an architect’s lens. Within moderation, of course.
### How I Use Obsidian for Everything (But Code)
URL: https://blog.kyleelliott.net/how-i-use-obsidian/
Last updated: 2025-06-12T12:00:33.000Z
I’ve tried a lot of note-taking tools. Apple Notes, Notion, Bear, Google Keep—you name it. They all have their strengths, but when I needed something that could scale with my brain with little fuss, I landed on Obsidian.
Obsidian isn’t flashy, but it’s powerful. Markdown-based, locally stored, and endlessly customizable. It’s become the digital equivalent of my second brain.
Here’s how I use it.
# 1\. Daily Notes & Journaling
Obsidian’s daily notes plugin is the backbone of my system. Each day gets a timestamped page where I:
• Brain dump in the morning
• Jot down any “in-between” thoughts throughout the day
• Review in the evening with a short reflection or summary
It’s low pressure and messy by design. Some days are just one line. Others turn into miniature essays. Both are valid.
# 2\. Managing Life’s Little Details
I’ve replaced Apple Notes with Obsidian completely. Packing lists, blog post drafts, snippets of ideas—it all lives here. I use tags like #packing, #errands, or #writing to keep things findable.
Backlinks help too. I might have a note for a trip, and link related packing lists or itinerary notes. No folders necessary.
Image generated with AI assistance
# 3\. Not Everything Needs to Live Here
Even though Obsidian is the heart of my system, it’s not the only tool.
For structured data, like media tracking, freelance projects, or detailed content calendars, I use Notion. Tables and databases just handle those types of workflows better than markdown files can. I can filter, sort, view different properties, and build dashboards tailored to what I’m doing.
I still link between Obsidian and Notion when needed (like tracking when I worked on a blog post), but I’ve learned to let each tool shine at what it does best.
# 4\. Connected Thinking (Without Overengineering)
I’ve learned not to over-tag or over-link. But when something does naturally connect, like two articles on similar topics, I’ll link them. Slowly, a little web of thoughts emerges in a nice visual.
The graph view? I'm finding it really helpful to diving into topics I'm into. Sometimes the combination of backlinks and tags will show a relationship I hadn't noticed before.
# 5\. What I’d Still Like to Figure Out
```
• A cleaner way to handle templates (I still just copy/paste from a “boilerplate” note)
• Better mobile support—it’s fine, but not great
• Maybe integrate some automation via Shortcuts or n8n later?
```
A year or so ago, I realized that it's not productivity that I liked, it was making the systems that helped with productivity. Now, I just want to use the tool to get my work done and go on with my day.
If you’re still using sticky notes or scattered apps, give Obsidian a try. It won’t solve everything overnight, but it gives you space to think, and that’s harder to come by than it should be.
*P.S. If you’ve ever exported 400+ Apple Notes into Markdown and had to clean them up one-by-one: I see you. It gets better.*
### The Road to Hosting Myself
URL: https://blog.kyleelliott.net/the-road-to-hosting-myself/
Last updated: 2025-06-07T11:00:50.000Z
When I first started looking into picking up more freelancing work, I wasn’t planning on becoming a part-time DevOps engineer. Although, I find it rather fun.
I wanted to keep costs low and maintain control, which meant doing things myself: buying the domain, setting up a VPS, managing DNS, building out reverse proxies, containers, and the whole nine yards. It was a lot to learn.
I tried a handful of VPS providers early on. Some with eye-catching “$4/month” offers that quietly doubled after a few billing cycles. Others were fast but locked to one region. Some had zero support, or left security and firewall management entirely up to me without clear documentation.
Eventually, I stopped looking for the perfect fit and started looking globally.
That’s when I found Hetzner, a provider based in Germany. Their pricing was honest. $8/month, no surprise increases, and within a few minutes, I had full control of a machine that’s been solid since. No speed issues. No flaky uptime. No drama.
I host my own site now.
My contact form feeds into a backend I built.
I even run my own blogging platform.
There were growing pains. Firewall configs and security tweaks. It took me a bit to reconfigure the Docker Compose that was set up for my local machine to remap to the VPS directories. But eventually, it all clicked. I built a space I trust, one that I understand from the ground up.
Would I recommend this to everyone? Probably not. But if you’re freelancing or building something for yourself, and you want full ownership of your stack? It’s worth it. These aren’t just technical wins They’re transferable skills you can bring to any client engagement.
Sometimes the best way to learn (or relearn) is to build the thing yourself, break it, and figure out how to fix it. It's good to be back at it.
### A Foldable Apple Powerhouse: My Dream All-in-One Device
URL: https://blog.kyleelliott.net/a-foldable-apple-powerhouse-my-dream-all-in-one-device/
Last updated: 2026-07-25T00:45:25.000Z
I know Apple loves its product ecosystem. I also know they’d rather sell me three different devices than one that replaces them all. But if they *did* decide to make my dream device, it would be a portable, foldable, all-in-one powerhouse that fits seamlessly into my setup.
Think iPhone when closed, iPad Mini when unfolded, and Mac when docked — without all the usual trade-offs.
### **The Device: A Pocketable iPad That Becomes a Desktop**
*A device that looks like a standard iPhone but unfolds into something closer to an iPad Mini.* But it doesn’t stop there — dock it, and it transforms into a desktop workstation with boosted performance and full external display and peripheral support.
### **Key Features**
**Portability:** Small enough to fit in my pocket when folded. It would function like any other iPhone
**Tablet Mode:** Expands into a larger display for browsing, sketching handwritten notes, or reading.
**Desktop Mode:** When docked, it gets a power boost and connects to peripherals. Which brings me to…
**Gaming-Ready:** Extra GPU/CPU power kicks in when docked — maybe even enough for Apple Arcade titles that *don’t* feel like mobile games. Apple has been trying to push into the AAA gaming market in recent years… maybe this would help.
It sounds too good to be true because it probably is.
This image was generated with AI assistance
### **How I’d Use It (a.k.a. Why I Want It So Badly)**
The real reason I want this device isn’t just because it sounds cool — it’s because it would actually fit very well into my daily life. Both personal and professional.
**Morning Work:** Dock it at my desk, plug into a monitor, and get a full macOS-like experience for coding, writing, or whatever else needs doing.
**Lunch Break:** Undock, head out with it in phone mode for calls, quick Slack replies, or scrolling news.
**Tablet Mode for Downtime:** While eating, unfold it into iPad size to read an article, watch a video, or take notes.
**Evening Relaxation:** Back at home, dock it again — this time for casual gaming with a controller, using that extra GPU power to make it something *more* than just a mobile device.
**Pocketable Convenience:** When I’m done, I just fold it back up and carry it like a regular iPhone — no extra bulk, no juggling multiple devices. No more carrying a backpack just to bring my iPad Mini with me places.
This would replace my iPhone, iPad Mini, and MacBook Air in one shot. Which, again, is exactly why Apple would never go for it.
Keep in mind the folded form factor could still work with things like the [Backbone](https://amzn.to/3XyLX8c?ref=blog.kyleelliott.net) (affiliate link). I currently use one with my iPhone 16 Pro Max and it’s great. So the mobile-centric games could still benefit.
### **Why This Won’t Happen (But Should)**
Let’s be honest — Apple isn’t exactly in the habit of *consolidating* their product lineup. If this device existed, it would cannibalize:
• **The iPhone** (because it would be an iPhone and more).
• **The iPad Mini** (because why buy one if your phone turns into it?).
• **The Mac Mini/MacBook Air** (because Desktop Mode replaces both, in some cases).
Apple *loves* its segmentation. They want you buying separate devices for separate needs, not an all-in-one solution that eats into their profits. Though, I do think power users like video editors, AI devs, etc. would still go for the standalone devices.
That said, if any company *could* pull this off without making it feel gimmicky, it’s Apple.
### **Does Anything Like This Exist?**
A few companies have dabbled in similar ideas, but nothing quite nails it:
- **Samsung’s Galaxy Z Fold** gets close with its phone-to-tablet flexibility, but Android tablets are still… Android tablets (in my opinion).
- **Samsung DeX** and **Motorola’s Ready For** let phones act like desktops when plugged in, but the experience is *meh* compared to an actual computer.
- **Razer’s Project Linda** tried turning a phone into a laptop, but I don’t think that it ever made it to market.
So no, nothing like this exists in general. I think if Apple made it, it would be polished and optimized in a way that the competition just doesn’t match.
**Concerns: Will It Hold Up Over Time?**
For a device like this to be my *main everything-device*, I’d need confidence that it won’t fall apart in two years. But, well…
- Flexible screens wear down faster than rigid ones.
- Heat from high performance + portability = potential long-term issues.
- It’s a perfect excuse for Apple to push AppleCare+ even harder.
That last point? Yeah, Apple would find a way to make sure we pay for durability. If this actually came to fruition, I wouldn’t mind.
### **Final Thoughts: Let Me Dream, Apple**
I know this device is wildly impractical from a business standpoint, but it just makes too much sense for the end user. Instead of juggling multiple Apple devices, we could have **one** that adapts to how we use it throughout the day.
Will Apple ever make it? Unlikely…
Perhaps someone with better business acumen could figure out how much this thing would need to cost so that Apple wouldn’t mind cannibalizing some of their other product lines. Even then, I don’t think the device would be for everyone anyway. I think most people would like to keep their devices separate.
Would I pre-order it faster than I’ve ever ordered anything before? 100%.
### **What about you?**
Would you ditch your current Apple setup for an all-in-one foldable, or do you prefer keeping your devices separate? And the real question — what do you think Apple would charge for this thing? Drop your guesses in the comments.
### Low-Code vs Pro-Code: Why I Stopped Picking Sides
URL: https://blog.kyleelliott.net/low-code-vs-pro-code-why-i-stopped-picking-sides/
Last updated: 2025-07-13T19:27:13.000Z
For years, I was a bit of a snob about low-code and no-code tools. If it didn’t involve writing real, robust, and well-documented code, it felt like cheating. Or worse — something destined to break the second it hit production.
But here’s the thing: life comes at you fast. And the busier I got, the more these tools started to make a whole lot of sense.
### **Low-Code Converts You One Workflow at a Time**
It’s not that I suddenly think low-code is the perfect solution for every project, it’s not. But when you’re trying to get from “idea” to “working prototype” in the same afternoon — without sacrificing your entire weekend — low-code is a damn gift.
### **Enter: Boomi**
One tool I’ve gotten pretty comfortable with in my professional life is **Boomi**. If you’re not familiar, Boomi is an integration platform that handles ETL (Extract, Transform, Load) processes, API management, and more — all with a heavy lean toward drag-and-drop and configuration over code.
What I like about Boomi:
- Quick setup for data mappings and transforms.
- You can still write custom scripts when the built-in stuff isn’t enough.
- It even lets you host and manage APIs directly inside the platform.
- In some cases, Boomi can *be* your APIM, which is surprisingly handy.
What I don’t like? Well, Boomi’s got quirks for days — but that’s a rant for another article.
Low-code concepts, generated with AI assistance
### **Automate Your Day with Apple Shortcuts**
Personally, my favorite low-code playground is **Apple Shortcuts**. If you’ve got a Mac, iPhone, or iPad, you already have access to this, and if you’re on Android, Google has **Routines** and **Tasker**.
Shortcuts is weirdly powerful if you take the time to mess with it. I’ve built some routines that save me a ridiculous amount of time, like:
- A “Leave the House” shortcut that turns off my smart lights, checks the weather, and pulls up my calendar.
- Push a notification when I get the to store, and open my grocery list when I tap it.
- Add reminder to take out the trash — but only if it’s not going to be too windy overnight.
- Build templates for common notes I take.
The trick is thinking about the things you do **all the time** and seeing if Shortcuts can automate even part of it. The less friction, the better.
### **Other Tools Worth a Look**
This list isn’t exhaustive (and I’m sure some no-code evangelist will flood the comments with their favorites), but here are a few others I’ve either used or keep hearing about:
*Zapier* — Gluing together all the SaaS you forgot you subscribed to.
*Power Automate* — Like Shortcuts, but for enterprise life (aka SharePoint purgatory).
*Airtable* — Spreadsheets, but cute and dangerously powerful.
*Make* — Zapier on steroids if you want to chain together more complex flows.
### **Final Thoughts: It’s a Toolbox, Not a Religion**
Look, I’m never going to be a full no-code convert. But I’ve finally stopped treating these tools like they’re poison. Sometimes you need a scalpel, sometimes you need a chainsaw, and sometimes you just need a big roll of duct tape and bubble gum.
Low-code used to feel like duct tape, and lately, I’m realizing that’s not a bad thing. Sometimes timelines are tight. I’ve come to learn that I value my personal time too much to automate personal tasks with code when a Shortcut can do the job.
**What about you? Got a favorite shortcut, automation, or low-code trick you swear by? Drop it in the comments — I’m always looking for ideas (and excuses to tinker).**
### Maven, Azure DevOps and SonarCloud
URL: https://blog.kyleelliott.net/maven-azure-devops-and-sonarcloud/
Last updated: 2025-07-13T19:38:38.000Z
While I admit I’m no Java guru, trying to get this up and running took me some time. So, I’m putting it here as a reference for myself later on and to help out anyone who may run into similar problems. This is how I set up and used Maven builds with [Azure DevOps](https://web.archive.org/web/20220316111306/https://azure.microsoft.com/en-us/solutions/devops/) and [SonarCloud](https://web.archive.org/web/20220316111306/https://sonarcloud.io/) integration.
#### The Pom File
There are a couple important things to note in the Pom file. The SonarAnalyze task in Azure DevOps has been deprecated and is no longer used for Maven builds. To utilize Maven builds with Azure DevOps and SonarCloud they want you to run the code analysis within the Maven build step instead. So our settings need to go into the Pom file. In the properties section you will define the sonar settings. Before you set this up you’ll want to go to the security tab in your account settings or the organization settings in SonarCloud to get a security token to use here.
The properties:
```
UTF-8 1.8 1.8 1.8
```
```
${project.basedir}/target/jacoco/jacoco-ut.exec ${project.basedir}/target/jacoco/jacoco-ut/jacoco.xml java jacoco reuseReports https://sonarcloud.io [comma delimited exclusions]
```
```
[org name here] [Project key here] [SonarCloud auth token (org or user)]
```
The important thing to know about what’s above is that SonarCloud deprecated support for the Jacoco exec output. They added a new option called *sonar.coverage.jacoco.xmlReportPaths* which you use alongside *sonar.jacoco.reportPath*. You need to point the XML report path to the XML file that is generated by Jacoco in your project which is defined further down the Pom file. Leave the report path in so that coverage is displayed in the pipeline build output. For exclusions, use wildcards for directories and exclude specific java files, not the Java classes. See this page for [details](https://web.archive.org/web/20220316111306/https://sonarcloud.io/documentation/project-administration/narrowing-the-focus/).
For the plugins there are a couple entries:
Lastly, profiles…
```yaml
sonar
https://sonarcloud.io
[organization]
true
org.jacoco
jacoco-maven-plugin
prepare-agent
prepare-agent
report
report
org.sonarsource.scanner.maven
sonar-maven-plugin
```
### The Pipeline
I did all of this with a Docker build, but the simple steps are:
1. SonarCloud Prepare
2. Maven — Set *sonarQubeRunAnalysis* to true
3. Publish Code Coverage Results
4. SonarCloud Publish
5. Publish Test Results
Before checking this all in create the project in SonarCloud so it has somewhere to publish the data to. If you don’t do that it will only create the project in SonarCloud when building against the master branch. It will not publish the data with the initial pull request. A work around for this if you do not have permission to create projects is to disable build policies to get the first pull request through and re-enable the policy again after it completes.
I hope this can help someone out!
### Automating APIM Updates with Swagger via DevOps
URL: https://blog.kyleelliott.net/automating-apim-updates-with-swagger-via-devops/
Last updated: 2025-06-04T18:53:57.000Z
Until recently, I did not have too much experience with Azure API Management (APIM). However, using a Swagger doc to import endpoint data under the Open API option clears the public URL. There are two problems there. First, I had to manually import the Swagger doc for each environment after each deploy. That’s a huge waste of time. Second, the import was clearing values that it shouldn’t.
Because of this I set out to try to automate this process. There are Powershell modules programmatically change APIM from Microsoft. I was able to get most of the way using Powershell on my local machine, but needed to run it in the pipeline in order to have full access to what the process needed. I ran into a bunch of issues there such as the commands could not be found. That’s when I found another link in Azure DevOps that pointed to a different set of documents that did pretty much the same thing…
It looks like Azure uses a different set of Az commands to perform this sort of functionality within a build/release pipeline. This documentation was rather vague. It didn’t state where the parameter values should come from and there were no examples. Being unfamiliar with APIM I, teamed up with a coworker to figure out what values each parameter should have with some trial and error. Below was what worked for me.
**Azure CLI Task Configuration**
> \- task: AzureCLI@2
> inputs:
> azureSubscription: ‘\[service connection here\]’
> scriptType: ‘pscore’,
> scriptLocation: ‘inlineScript’
> inlineScript: ‘\[az afim api import script detailed below\]’
> Az aim api import script
> az apim api import — specification-format OpenApi — specification-url \[url to spec file\] — service-url \[URL the service is exposed on\] — resource-group \[name of resource group the APIM instance is in\] -n \[name of APIM\] — api-id \[name value in API settings tab\] — path \[URL suffix (“/” if empty)\]
Small side note. If you run into a Service Unavailable error when running the import add a Powershell task with \`Start-sleep -Seconds 60′ between the deploy and the import. The service is still spinning itself back up and is unavailable for import during that time.
Once we figured out what went where in the command it was smooth sailing. I hope this can help to make this process easier for the next developer. Until next time!