The spreadsheet running the company
A fragile macro holds critical processes together. One wrong cell and everything stops.
Technical solutions for real-world problems
Something isn’t working.Let’s figure out what.
I help small businesses and teams untangle processes, connect tools and decide what needs to change. Sometimes that means building something new. Sometimes it means less software.
Notice. Question. Resolve.
Find the loose end.
Make the right change.
How we think
Some problems
worth untangling.
Illustrative scenarios, not completed client projects.
One update. A clear path.
ILLUSTRATIVE EXAMPLEBefore: three separate copies
Sales
Customer record
Operations
Customer record
Billing
Customer record
A possible approach: one maintained record
Customer record
SalesOperationsBilling
Decide who owns the record. Connect what needs it.
The tools can stay. The repeated entry doesn’t have to.
Payments tracked in a fragile workbook.
Illustrative scenario. The approach and intended outcome below are hypothetical.
Operations / Internal tools
The problem
The business depends on a spreadsheet to track payments. Updating it feels risky, and checking what is outstanding takes too much time.
What I’d investigate
The real friction is not “Excel is bad.” Payment records, notes and status updates have become entangled, with no clear source of truth.
What I’d change
A sensible intervention would separate the records from the reporting, make ownership explicit, and build a small shared tool only if the existing workflow cannot support that.
What success could mean
A payment process people can understand and maintain. Success would be assessed through fewer reconciliation mistakes and less time spent finding the right information.
One update. Three places to enter it.
Illustrative scenario. The approach and intended outcome below are hypothetical.
Processes / Integrations
The problem
A team copies the same customer information between three systems. Work slows down, and the copies gradually disagree.
What I’d investigate
Each tool has a reason to exist. The missing piece is a decision about who owns each record and how a change moves between systems.
What I’d change
Map the information flow, establish the source of truth, then connect the existing tools where appropriate. Replace only what is genuinely preventing a workable process.
What success could mean
One reliable update instead of repeated entry. Success would be assessed through fewer mismatches and less manual effort, not by how many new tools were added.
Common problems, different perspective
Familiar problems. Clearer solutions.
Real situations. Practical fixes. Lessons that stick.
Systems that don’t talk
Customer data lives in several places and nobody trusts which one is correct.
The project that’s always almost done
Many active tasks, little finished work. The same bottlenecks, again and again.
Recognition, not a sales pitch
Sound familiar?
“We have this spreadsheet…”
…and everyone is afraid of breaking it.
“We enter the same information three times.”
Surely once should be enough.
“Only María knows how this works.”
And María deserves a holiday.
“These five tools are somehow one process.”
That’s a lot of places for context to get lost.
“We need an app.”
Maybe.
The way through
So what do we do?
Sometimes the answer is a new tool. Sometimes it’s connecting what you already have, or changing the process. We figure that out before deciding what to build.
Understand
Map the process, the people and the point where things get stuck.
Question
We challenge the assumptions. Including the solution you thought you needed. Especially that one.
Recommend
Choose the smallest sensible change that solves the real problem.
Change
Build, integrate, automate, simplify, remove — or help your team make it happen. Whatever the problem actually needs.
The toolkit, not the pitch
Okay, but what can emm-g do?
Figure it out
You know there’s a problem. We’ll work out what needs to change.
Make things talk
Systems shouldn’t need a human copy-pasting information between them.
Build what’s missing
When the answer really is custom software, we’ll build the useful part.
Make what’s there better
Improve the workflow before replacing the tools.
Help your technical team
Another experienced brain when your team hits a decision worth getting right.
Less software. Better flow.
Simplify the system
You might not need more software. Remove unnecessary dependencies and see how a clearer architecture emerges.
Two fewer things to maintain.
Fewer dependencies. Easier to reason about.
Trade-off: fewer links isn’t always better. A connection earns its place when it removes manual work. Here, the sync job and CSV export only patched gaps between the others.
Small by design
Tiny on purpose.
Fewer handoffs. Fewer games of telephone. More context stays in the room.
Emmanuel González
The human behind the tired eyes.
emm-g is a small technology consultancy built around a simple advantage: the person understanding your business problem can follow it through product, design, engineering and technology strategy.
I’ve worked across software engineering, product, design and technical leadership. That range lets me look at the same problem from several angles before deciding which one actually matters.
- Engineering
- Product
- Design
- Technical leadership
A thought to take with you
More software isn’t always better software.
Good technology should remove friction, not relocate it.
Start with the messy version
What’s not working?
You don’t need to know what you need yet.That’s kind of the point.
Prefer email?
Draft restored
Your message from earlier is back.
MESSAGE SENT
Got it.
Thanks for sharing the messy version. I’ll take a look.
Your message has been sent. I’ll reply to the email address you provided.