Hey, I'm
Bianca.

I did not ask to become a developer. I just ran out of ways to make Excel do things it was never designed to do.

The first time I actually fixed something properly was 2012. I had a document I had to produce for every work request - copy-paste data from multiple sources into a form, package it as a PDF, email it to five different people. Twenty to thirty minutes per request. About 70% had at least one error in them. Wrong data sent to the vendor. Techs arriving onsite for installs with incorrect information. Support fielding the calls. The week I was there by myself doing the job of four others was the worst.

IT had looked at automating it. I gave them the requirements, and they gave me crickets.

So I did it myself. Excel had an import web page feature I'd never seen anyone use. I learned and tested extensively with formulas to get the output to work, VBA handled the rest - both documents populated, PDFs packaged, five emails sent. Under two minutes.

I'm a citizen developer - someone who bridges the gap between the business problem and the code that fixes it. Not by waiting on a ticket. By building it myself.

Version 1.0: Excel & VBA

The formula work came first. INDEX MATCH, variable logic, dynamic ranges - formulas were how I understood data before I understood code. VBA was always the last resort. The document formats in that 2012 fix were formula-driven; VBA just packaged what the formulas had already built, sent the emails, and got out.

Then the team grew. Multiple people needed access, audit trails became mandatory, and version control lived entirely in the file name. At some point there were four copies of the same workbook and no one was certain which one mattered. I needed more flexibility.

Version 2.0: SharePoint Lists

By 2015 the trigger was Local Number Portings - a process that needed a single source of truth, something both sides could access and edit without emailing spreadsheets back and forth. If you haven't worked with Lists, they're like spreadsheets that have taken performance-enhancing stimulants. The WWE superstars of the Microsoft stack. Multi-user, structured, no version conflicts in the file name. Everyone working off the same record.

But the process still ran on goodwill and manual steps. The logic lived in my head, not in the system. If I went on leave, things stopped working.

Version 3.0: Power Platform

If SharePoint Lists are the WWE superstars, Power Platform is MMA - and Power Apps is its Conor McGregor. More technical, higher ceiling, and a lot more personality than anything that came before it.

In 2018 I picked up Flow - now Power Automate. I started with document approval workflows, learned to manipulate SharePoint lists with JSON, then started editing Word documents dynamically inside the flows themselves. By the time I'd built a Power App to manage all of it, I owned the whole stack: data model, automation, interface, analytics, without a single IT ticket.

When it runs out of road, I extend it: Office Scripts triggered by Power Automate, custom APIs consumed by Power Apps, React front-ends fed by Power BI datasets. The platform is a starting point, not a cage.

What this is

I built my own infrastructure when the systems failed me. I'm now documenting my steps so you don't have to start from scratch.

This is a blueprint - every post leaves you with something you can take straight into your work.

It's for the person who knows the logic exists, can see exactly how it should work, and has been told it isn't possible - usually by someone who hasn't tried.

I am Bianca. I make your tools work like they should