- Software Engineer and Project Lead Izzy Hymas learned early that questions asked upfront are cheaper than rework done later.
- A real MVP isn't a cheaper version of the product — it's a boundary that keeps scope, budget, and momentum from quietly slipping.
- Not every problem needs custom software: integration only earns its cost once off-the-shelf tools stop talking to each other.
- On a recent project, she connected Recurly, TripleSeat, and Calendly around Zoho CRM — replacing manual re-entry across four platforms with one source of truth.
Izzy Hymas remembers exactly which project taught her the lesson. It was one of her first CRM integrations at Virgo Development, and it looked straightforward going in: connect a client's systems, move some data, automate a few manual steps. Work started before every field mapping, data behavior, and edge case had been fully worked out.
It didn't take long to find the gaps. Fields that were supposed to sync didn't line up the way anyone had assumed. Decisions made in the first week had to be unwound in the fourth. The fix itself wasn't complicated — but the rework was, and it cost far more time than the conversation that could have prevented it in the first place. "Questions upfront are cheaper than rework later," she says now, and that lesson has become the thread running through almost everything else she has to say about building good software. I sat down with her to talk through it.
01 — Meet Izzy
From Self-Taught Coder to Project Lead: Who Is Izzy Hymas?
Izzy's path into software started with curiosity — she taught herself to code because she liked figuring out how things worked. That curiosity carried her through Dixie Technical College and into a role at Virgo Development, where she's grown from writing code to leading projects, often the same projects she's also building. Her technical focus splits between frontend work and CRM integrations connecting platforms like HubSpot and Zoho to custom business software.
What's changed as she's taken on more project responsibility isn't her interest in the work itself. It's what she now notices before she starts solving a problem.
02 — Lesson one
Why Do the Best Engineers Ask More Questions Before They Build?
A request and a requirement aren't the same thing, and Izzy treats the gap between them as part of the job. When a feature request comes in, she doesn't start with how to build it. She starts by asking what problem it's actually meant to solve, what should happen once it exists, and what the simplest version that solves it would look like.
"A good engineer can build what was requested. A great engineer understands what the client is actually trying to solve."
— Izzy Hymas, Software Engineer & Project Lead, Virgo Development
It's a small distinction with a big effect on outcomes. Teams that skip it can build the request precisely and correctly — and still miss the mark. The reason it matters so much comes down to timing: the same clarifying question costs almost nothing during discovery and a great deal more once code has already been written around the wrong assumption.
03 — Lesson two
What Makes an MVP Actually Work — Instead of Just Being a Smaller Product?
Projects that look simple on paper have a way of growing teeth once work begins, and Izzy has seen the pattern often enough to be blunt about it: a clear MVP isn't a cheaper version of the software. It's the boundary that keeps a project moving.
"Start with the simplest version that solves the core problem. It's easier to adjust an MVP than to rebuild something that missed the mark."
— Izzy Hymas, Software Engineer & Project Lead, Virgo Development
A few signs that boundary has gone missing tend to show up on real projects:
- The request keeps changing shape mid-build, without anyone deciding that on purpose
- No one can point to a clear definition of "done"
- Small, reasonable-sounding additions stack up without anyone weighing their combined cost
None of those are dramatic on their own. Together, they're how a two-week project quietly becomes a two-month one.
04 — Lesson three
When Does a Business Need a Custom Integration Instead of an Off-the-Shelf Tool?
Not every problem needs new software. Off-the-shelf platforms like HubSpot and Zoho are strong starting points for a reason, and Izzy is quick to point that out before recommending anything custom. The moment integration work earns its cost is when those systems stop talking to each other — when a team is re-entering the same data twice, or a built-in connection can't handle what the business actually needs it to do.
05 — Case study
Making Zoho CRM the Center of a Connected Workflow
That's the shape of a Zoho integration Izzy built for a hospitality and events client — connecting Recurly, TripleSeat, and Calendly so information could move between systems automatically, instead of being checked and re-entered by hand across four platforms.
The value wasn't the integration itself — it was what stopped happening because of it:
- Less manual data entry across billing, events, and scheduling
- Fewer disconnected systems for the team to reconcile by hand
- More reliable, consistent data flowing into reporting
- Easier, faster marketing operations built on data the team could actually trust
It's the CRM-forward version of the same lesson: understanding how data actually needs to move through a business — before writing a line of integration code — is what makes the integration worth building. For a deeper, more technical look at how this kind of connection gets built, see Izzy's own breakdown of how CRM integrations actually work.
06 — Lesson four
Why Is Duplicated Code Future Rework in Disguise?
Izzy's attention to detail shows up in smaller ways too — most notably in how she reacts to duplicated code. It's not a style preference. Repeated code is future rework waiting to happen: a bug fixed in one place and still broken in three others, a change that should take an hour instead touching every copy separately.
That instinct extends into how she thinks about tradeoffs generally. Speed, budget, elegance, and reliability all have to be balanced against each other on a real project — but for Izzy, some things aren't up for negotiation. Data integrity, security, and reliability don't get cut to move faster. Everything else can flex around them.
07 — Project leadership
What Changed When Izzy Started Leading Projects, Not Just Building Them?
Taking on project leadership hasn't changed what Izzy values about good code. It's changed what she pays attention to before writing any. Good code is still the job — but it's no longer the whole job. Understanding the business goal behind a request, communicating constraints honestly, protecting scope, and flagging downstream impact before it becomes an expensive surprise are just as much a part of building software well as the code itself.
It's a natural extension of the lesson that opened this article: the best project leadership doesn't sit on top of engineering. It is engineering, applied a little further upstream.
08 — AI in the workflow
Does AI Replace Engineering Judgment, or Just Speed It Up?
AI has changed the pace of Izzy's day-to-day work — she uses it daily, and it's made a real difference in how quickly she can move. What hasn't changed is what happens after: she still reviews the code, and she still writes the tests. Faster tools are only valuable when the engineer using them still understands what's being built and why. Fundamentals, testing, and communication don't become optional just because the first draft comes together faster.
Before You Spend the First Dollar
Izzy's advice for a business owner considering custom software or a CRM integration comes down to a short list of questions worth answering before any development work begins:
- What problem are we actually solving?
- What does success look like when this is finished?
- What are the core components the first version needs — and what can wait?
- What systems need to talk to each other, and what happens if they don't?
"Custom software is not always the first answer. Sometimes the best solution is already in the tools you have." — Izzy Hymas
09 — Common questions
Quick Answers
Why do better questions upfront save money on a software project?
Because the cost of a change rises the later it's caught — a question during discovery costs minutes, the same fix mid-build costs days of rework, and after launch it can cost a rebuild.
What makes an MVP different from a stripped-down product?
An MVP is a boundary, not a discount. It's the simplest version that solves the core problem — a deliberate starting point that's easy to adjust later, instead of a rebuild waiting to happen.
When should a business build a custom integration instead of relying on off-the-shelf tools?
When systems stop talking to each other — when a team is re-entering the same data twice, or a native connector can't handle what the business actually needs it to do.
What separates a good engineer from a great one?
A good engineer can build what was requested. A great engineer understands what the client is actually trying to solve — and builds toward that instead.
Izzy's story is really one small case study in a bigger habit: the best engineers don't just write good code, they protect a project from the questions nobody asked yet. Getting clear on scope, the MVP, and what actually needs to talk to what is the same curiosity that got her into code in the first place — just aimed a little earlier in the process than it used to be.
Have a workflow that depends on disconnected tools or too much manual work? Book a Discovery Call and let's find the simplest path forward together.
Jamie Lords ↗ LinkedIn is CEO of Virgo Development and teaches Business and Marketing at Southern New Hampshire University. This piece continues VirgoDev's engineer interview series spotlighting the people building the company's custom software, integration, and platform work. Quotes are drawn from a conversation with VirgoDev Software Engineer and Project Lead Izzy Hymas, lightly edited for readability.