The Path the Engineer Expected vs. the Path the User Took

Ian Anderson knew exactly how the puzzle was supposed to work. His five-year-old son had a different idea.

Ian had just finished changes to a puzzle activity for Miss Humblebee's Academy, a learning platform built for children ages three to six. Before the update went out, he asked his son to give it a try. In Ian's mind, the interaction was obvious: click a puzzle piece in the sidebar, then drag it into place.

His son skipped the click entirely. The very first thing he did was try to drag the piece straight from the sidebar into the puzzle, and the activity wasn't built to handle that. That one test led to changes and improvements before paying customers ever saw the update.

For Ian, it was a clear reminder of something he brings to every project: when you know how the code works, an interaction can feel obvious even when it isn't obvious to the person actually using it.

01 — Where it started

From the Classroom to the Full Stack

Ian is a software engineer and mobile app specialist approaching his first year at Virgo Development. He is a graduate of Dixie Technical College's Mobile App Development program, and he joined Virgo as the team was expanding its mobile app capacity. It was a natural fit.

His interest in programming started with a college assignment to build a Sudoku solver in assembly language. The code didn't make much sense to him at the time, but the idea that a computer could solve that kind of problem hooked him. Later classes in C++ and Python turned that curiosity into a genuine love of programming.

At Virgo, Ian has taken the initiative to grow into full-stack development and has earned ownership of projects as his skills have expanded. Today he's most at home on projects with lots of moving parts, including:

• User-facing interfaces for web and mobile apps
• Backend logic that keeps data accurate and the app responsive
• Integrations that connect platforms, from content tools to eCommerce

As he puts it, if a project involves Django, Vue, Capacitor, Framer, or Shopify (or all of them at once), he can handle it.

02 — Discovery

A Better Question Can Change the Build

That full-picture thinking showed up on Creator Studio, a tool Ian built for Miss Humblebee's Academy that helps teachers create classroom resources. (For more on the platform itself, see When Your Curriculum Becomes Software.)

What "offline" really meant

The owner said offline functionality was the single most important requirement. Instead of estimating an offline app right away, Ian sent her ten plain-language questions first. The answers changed everything:

• What it sounded like: an application that works without an internet connection
• What teachers actually needed: printable PDFs they could hand out in class
• What that meant for the build: a meaningfully smaller estimate before any other cuts were made

The owner then trimmed further. Teachers simply print and hand things out, so assignment features could wait.

"Asking 'what does a teacher actually do with this?' saved more time than any code I wrote."
— Ian Anderson, Software Engineer and Team Lead

One generator instead of two dozen tools

The original mockup showed roughly two dozen separate AI teacher tools. Ian built a single Printable & Resource Generator with a library of templates instead. Each resource type is defined by configuration (its prompt and its print layout), so adding a new kind of resource means adding a template, not building a whole new feature.

For a business owner, the lesson is simple: describe what someone will do with the result. A phrase like "works offline" can point to very different products with very different price tags.

03 — Mobile expertise

Mobile Expertise Includes the Device in Your Hand

Ian learned mobile development the traditional way: building native Android and iOS apps separately, which meant building every app twice. At Virgo, the team uses Capacitor, which lets one shared codebase power both platforms. (Kayson Sylvester's guide to Capacitor vs. native development explains when that's the right call.) That saves a lot of duplicated work. What hasn't changed, Ian says, is testing.

Android and iOS still handle key details differently, including:

• Safe areas around notches, camera cutouts, and screen edges
• Keyboard behavior and how the screen resizes when it opens
• Home indicators and gesture bars at the bottom of the screen

In one Parade app, a bottom-navigation bug showed up only on a physical Google Pixel phone. It didn't appear in previews, which is exactly why real-device testing belongs in the plan.

Ian also designs for how a screen feels. On the Miss Humblebee's classroom home screen, he moved slower recommendation work into the background so the screen loads first. And he notices the small things, such as text that isn't vertically centered with the button beside it. Details like that are what make an app feel polished.

04 — Fit for purpose

Choosing Tools That Fit the Job

Ian applies the same practical judgment to websites. For Elizabeth Hales Design, Framer was the right call:

• What Framer handled: a content management system and hosting, with no backend to maintain
• What the client gained: a team that can edit its own site
• What needed custom work: a contact form with dependent dropdowns, tracking, spam screening, and a CRM handoff, handled by a small custom script

The platform did most of the job, and targeted code handled what it couldn't. Ian also watches for the warning sign: when you find yourself layering more and more scripts onto a no-code tool, it may be time for a different approach.

When a request won't fit the budget or timeline, Ian favors phasing over a flat "no." Launch a simpler first version, then add to it. And he writes for the next engineer, too: in his view, a good engineer gets the job done, but a great one makes sure the code is clean, readable, and easy to update. It's the same idea behind his earlier piece, Complexity Is Easy. Simplicity Takes Discipline.

05 — AI & judgment

AI Helps With the Typing. Ian Owns the Thinking.

Ian is one of Virgo's internal advocates for AI-assisted development. He uses AI coding assistants for boilerplate, repetitive first drafts, and talking through a stubborn bug. But he's clear about where the tool stops.

"It saves typing, not thinking."
— Ian Anderson, Software Engineer and Team Lead

Architecture, data correctness, and privacy remain his responsibility. The generator-and-template design for Creator Studio came from understanding what teachers actually do, not from a tool. And every line gets reviewed before it ships.

"I review everything before it ships, whoever or whatever wrote the first draft."
— Ian Anderson, Software Engineer and Team Lead

06 — Advice for business owners

Before You Spend the First Dollar: Ian's Advice

If you're planning a mobile app or software project on a tight budget, Ian recommends three steps:

1. Answer the questions you're tempted to skip. Describe the user's real task, not just the feature you picture. The answers can reshape the build before anyone writes code.
2. Define version one in a single sentence. For Creator Studio, it was: tell Miss Humblebee what you need, generate, review or edit, print, save. Anything not in that sentence waits for a later phase. (More on that in The Aha Moment.)
3. Test with the people who'll actually use it. On real devices, with representative users. Sometimes that's a five-year-old.

Knowing your competition helps too. For Creator Studio, the goal of being faster and more polished than the general-purpose AI tools teachers already use told the team exactly where to invest: print quality, not more tools.

07 — What drives him

The Part Ian Enjoys Most

For Ian, the most rewarding moment comes when a client sees the work that went into a project and is genuinely happy with the result. His growing range of skills gives him more ways to solve a problem. Listening to the people who will use the software helps him choose the right one.

08 — Common questions

Quick Answers

09 — Let's talk

Have an App or Software Idea?

If you're working out what the first version of your product should be, engineers like Ian start with the people who will use it. Our mobile app development team will help you define a practical first release and test it on the devices your customers actually carry.

Ready to talk it through? Book a Discovery Call with me and the team, or email [email protected]. Discovery calls are free.