By Joseph Jaramillo, Vice President, Digital Services, Abba Technologies
Over the past several months, I have been building an internal project management platform for Abba Technologies called ProjectIQ.
When I say building it, I mean something that would have sounded a little unrealistic to me not that long ago. I have been working directly with AI coding tools to turn business requirements, workflows, ideas, and rough concepts into functioning enterprise software.
You could call it vibe coding.
But after going through the process, I think that term dramatically understates what is actually happening.
ProjectIQ started with a relatively straightforward goal: build an internal platform that better reflects the way we manage projects, financial performance, delivery risk, governance, and portfolio visibility.
Like many organizations, we could have continued adapting our processes around commercial project management platforms. We could have purchased another SaaS product. Or we could have followed the traditional custom software path, with requirements gathering, business analysts, architects, developers, UX designers, testing cycles, and a significant development investment before seeing a mature working product.
Instead, we tried something different.
From an Idea to Working Software
My background is in technology consulting, project delivery, and leading enterprise programs. I am not a software developer sitting down each morning writing production code.
What I do understand deeply is the business problem.
I know what information a project manager needs to see, what leadership needs at a portfolio level, and how project financials, budgets, forecasts, estimates at completion, gross margin, schedules, milestones, risks, issues, governance, change control, staffing, and delivery accountability fit together.
Historically, someone in my position would describe those requirements to a software team. A business analyst might document them, an architect would interpret them, developers would implement them, and eventually I would review what was built.
Then we would find the inevitable gaps between what I meant, what was documented, what was understood, and what ultimately appeared in the application.
AI has changed that loop.
With ProjectIQ, I can describe a problem, work through the workflow, challenge the proposed approach, review an implementation, test it, refine it, and continue iterating without losing the context of what we are trying to accomplish.
Instead of waiting weeks to see an interpretation of an idea, I can often see a functioning version of it very quickly.
That is more than a productivity improvement. It fundamentally changes the relationship between the person who understands the business problem and the process of creating the software.
The First 80 Percent Can Move Incredibly Fast
ProjectIQ evolved much faster than I would have believed possible a few years ago.
What began as an internal project management concept grew into a real application that includes project setup and activation, project financial management, deliverables and milestones, tasks and schedules, RAID management, executive dashboards, portfolio intelligence, role-based access, user administration, audit history, subcontractor financial management, and an AI assistant we call IQbit.
We are also designing ProjectIQ with future integration into other enterprise systems in mind.
The important point is not the number of features. It is the speed at which a business concept can now become working software.
A person with strong domain knowledge can take an idea dramatically farther than they could before. You can explore workflows, test assumptions, discover gaps, reject bad ideas, and refine the product while it is being built rather than trying to anticipate every requirement before development begins.
That is an enormous advantage.
It also creates a new danger: because the software appears so quickly, it becomes very easy to confuse working with finished.
ProjectIQ taught me that lesson early.
AI Did Not Get Me 100 Percent of the Way There
Eventually, the questions changed.
It was no longer simply whether a screen worked, whether I liked a workflow, or whether the application reflected the way our project managers operate.
The questions became more consequential.
Was the authorization model correct? Were we protecting data properly? Was the database model sound? Could we trust the financial calculations? Were database migrations safe? Were the deployment patterns appropriate? Were we creating technical debt that would become expensive later? Was a solution truly maintainable, or had we simply found a clever way to make something work?
Those questions require experience.
I could not have taken ProjectIQ all the way to where it is today without senior development and senior architecture review and support.
That is an important part of the story because it would be easy to look at what AI coding tools can produce and conclude that the traditional software team is becoming unnecessary.
My experience has led me to almost the opposite conclusion.
AI got me from an idea to functioning enterprise software faster than I would have thought possible. But it did not eliminate the need for senior engineering.
In many ways, it made senior engineering judgment more important.
The Role of the Developer Is Changing, Not Disappearing
There is no question that AI is going to remove a tremendous amount of friction from software development.
It can write code, create components, refactor existing implementations, generate tests, diagnose issues, and implement features that previously might have required hours or days of manual development effort.
But producing code and engineering a system are not the same thing.
An experienced developer or architect can recognize when something technically works but is architecturally wrong. They can identify security risks that are invisible from the user interface. They understand the downstream consequences of a data-model decision. They know when a solution has become unnecessarily complicated and, perhaps most importantly, when the AI is confidently solving the wrong problem.
That expertise becomes even more important when AI dramatically increases the amount of software an organization can produce.
The bottleneck moves.
Typing code becomes less scarce.
Technical judgment becomes more valuable.
I think this is one of the most important implications of AI-assisted development. The highest-value technical people may spend less of their time producing routine code and more of their time reviewing architecture, protecting system boundaries, making difficult engineering decisions, and ensuring that rapidly created software is actually worthy of production.
That is not the disappearance of the senior developer.
It is leverage.
Business Knowledge May Be Just as Important
ProjectIQ has also changed how I think about domain expertise in software development.
For decades, one of the most difficult problems in enterprise technology has been translation. The people who understand the business are often separated from the people building the software by several layers of process.
A business user describes what they need. Someone documents it. Someone else interprets it. A development team implements it. Eventually, the user tests it.
Every handoff creates an opportunity for meaning to change.
AI can shorten that chain dramatically.
If the person who deeply understands the business process can interact directly with the tools helping create the software, requirements become much more iterative. Instead of trying to perfectly describe a future application in a document, you can react to something real.
You can say, "That isn't how we actually work."
You can change it.
You can test it.
And then you can move forward.
That does not mean every executive should start building applications. Domain expertise alone is not enough to produce secure, maintainable enterprise systems.
But it does mean that people with deep business knowledge can participate much more directly in software creation than they could before.
That is a significant shift.
Vibe Coding Still Needs Engineering Discipline
One of the dangers in the current conversation around AI development is that impressive prototypes create a false sense of completion.
A prototype can look finished long before it is enterprise ready.
Authentication matters. Authorization matters. Auditability, data integrity, testing, recovery, deployment architecture, security, maintainability, and operational support all matter.
The things users may never see often determine whether an application can actually be trusted.
ProjectIQ has reinforced that lesson repeatedly. Some of the most difficult work has not involved adding new features at all. It has involved infrastructure, database migrations, security boundaries, deployment processes, and production-readiness issues behind the scenes.
Those problems are much less exciting than watching AI produce a new interface in minutes.
They are also where software engineering becomes very real.
AI makes building software dramatically easier.
It does not make engineering discipline optional.
This May Change the Economics of Custom Software
This is where I think the ProjectIQ experiment becomes much bigger than ProjectIQ.
For much of the past decade, the default answer for many organizations has been SaaS, and for good reason. Why invest in custom software when an existing subscription product can solve 70 or 80 percent of the problem?
Custom development was expensive, slow, and carried significant risk. As a result, organizations frequently adapted their processes around the software they purchased.
AI may begin changing that equation.
If AI can dramatically reduce the effort required to build the more routine portions of an application, custom software starts becoming economically viable in situations where it previously would not have been.
That does not mean SaaS disappears. There are countless situations where purchasing a mature commercial platform will continue to be the right decision.
But the build-versus-buy decision may become considerably more interesting.
Organizations may increasingly be able to ask a different question:
Should we change our business to fit the software, or should we build software that fits our business?
A few years ago, the economics frequently answered that question before the discussion even started.
That may no longer always be true.
A Different Model for Building Software
The development model I see emerging is not AI instead of people.
It is the combination of three things.
First, deep business expertise. Someone has to understand the problem well enough to know what should actually be built.
Second, AI acceleration. AI can dramatically compress the distance between an idea and working software, making experimentation and iteration much faster.
Third, senior engineering oversight. Experienced developers and architects make sure that what gets built is secure, scalable, maintainable, and production ready.
Those three elements reinforce each other.
Business expertise without engineering can create software that reflects the workflow but cannot safely operate at enterprise scale. Engineering without sufficient business context can produce an elegant solution to the wrong problem. AI without either can generate an extraordinary amount of software very quickly, including software that should never make it into production.
Put all three together, and something much more interesting happens.
Senior technical talent can spend more time making high-value architectural decisions. Domain experts can participate directly in shaping the product. AI absorbs a growing amount of the repetitive implementation work between them.
That has the potential to change both the speed and the economics of software development.
What ProjectIQ Taught Me
I started ProjectIQ because we wanted better internal project management software.
I did not expect the project to change how I think about software development.
But it has.
AI is not removing the need for talented software engineers. It is changing where their expertise creates the most value.
It is not removing the need for product thinking or business analysis. It is giving people with deep domain knowledge a much more direct role in creating the solution.
And it is not making enterprise software easy. The hard engineering problems are still hard.
What AI is doing is dramatically shortening the distance between an idea and something tangible enough to test, challenge, improve, and eventually put into operation.
For organizations that have spent years working around spreadsheets, disconnected systems, aging internal applications, or commercial platforms that only partially fit the way they operate, that creates some very interesting possibilities.
The question may no longer simply be, "What software can we buy?"
Increasingly, it may also be:
"What software could we build?"
ProjectIQ started as an answer to an internal project management problem.
It ended up giving me a very different perspective on what custom software development may look like in the years ahead.
And I think we are only beginning to understand the implications.
If you're thinking about how AI-assisted development could change the way your organization builds internal software, feel free to connect with me or reach out directly at joseph.jaramillo@abbatech.com