The hor d’oeuvres are delicious.

The hor d’oeuvres were delicious. The dev team members, exhausted from many double-digit-hour long days were mixing with the business users and business leaders, and I, though peripheral to the effort, was among them. The venue was swank - overlooking the Hudson River with a view to New York City, the Freedom Tower, and the rest of its illustrious skyline. The senior manager in charge of the software delivery was smiling, and laughing, and popping in from group to group to thank the delivery leaders and to converse with the business. It seemed the entire set of business leaders for the delivery had shown up, from the business users up to the business Senior Management.

It was a big rollout! The delivery was to provide a streamlined front-end and numerous functional enhancements to manual processes the business had been enduring for years as the set of enhancements was funded, approved, defined, built, and rolled out.

“Nothing ever comes back”, said one manager to me as I met various stakeholders at the rollout party. “It takes 45 minutes in the screen, before the operation fails”, said another. By the end of the party, I had determined that it might take 2 hours to enter a single user account from inception through to provisioning and finalizing a fundable account; that is, if it did not fail.

The contrast between the IT senior manager’s idea of his rollout and the view of the business was striking. As a senior Data Architect marginally involved with the software design and implementation (peripherally involved, and only engaged at the end when they suddenly realized they had not built any reports and hurriedly rushed some in), I could not understand the incongruity. How had the IT manager failed to understand the disconnect between the release’s goals and the actual user experience? How had the release made it through Test environments?

In post-release review, various checkboxes had been checked along the way: each functional unit test had been tested and passed in dev QA. The dev QA team had sent innumerable bugs back to the development team, but, in each instance, the bugs had been fixed, the test cases had passed, and the feature that was specified was certified as being fully implemented.

Similarly, in UAT, each test performed looked at one feature or functionality, and in each case, the features ultimately passed, albeit in many cases being sent back to dev QA and development.

So what had happened?

1) there was no spec for technical requirements such as Service Level Agreement (SLA) for amount of technical resources required (eg database server memory, storage, rollback space), but, more importantly, there were no business requirements for the time to retrieve or to perform an end-to-end account entry. Consequently, technically the entire release passed. Unwritten requirements do not get tested.

2) IT Manager had an angry temper. Killing the messenger was his Modus Operandi. There was a joke that was told about the tongue-lashing people would get. It was amusing until it was your turn. A joke went around about when it would be time for someone to be in the barrel.

That was the last party for that group of business leaders that IT Manager threw.

I have a feeling there are some AI initiatives where the unwritten requirements are about Data Completeness, Accuracy, and Availability, and about the reliability of the AI in correctly interpreting business rules or business data.

There may be some too afraid for their careers to say it: you are missing the full specification, or what is being built will not work as built.

My Mother Was Vibe-Coding Before Vibe Coding Existed

Before “vibe coding” had a name, my mother built software for nonprofits from library research, punch cards, and pure determination.

She eventually had more than 100 clients. Then they all started asking for changes.

When I was 11, I went with my mom to the Philadelphia Public Library. We emerged with 3 enormous bound books in her hands, the lists of all the foundations locally and nationally, foundation addresses and which programs each foundation supported. My mom said she was going to build software for non-profits, develop annual giving programs for them and funnels for funding.

———————————————————————————————————

This was on a Saturday. During the week, my mom worked at a software company where she typed in punch cards. Her attitude: these software coders aren’t that much smarter than me.

I viewed her the same way you humor anyone with a preposterous idea you already know will fail but don’t have the authority or heart to tell them - you just have to let them fail on their own. It’s your mother, and you don’t get to choose your family. Plus my mother was not someone you could easily tell anything, especially no.

Her company name: Data Development Services, Inc.

A couple of years later, my mother had over 100 clients. She had developed desktop software in a world of Fortran mainframes: it maintained email distribution lists, lists of the foundations, the dates various proposals were sent, contact details, due dates, the references to the underlying foundation requests, tracked the incoming funds, tracked the use of the funds against that budgeted amount, and tracked the non-profits’ programs and some details about the services provided.

A year after that, she wrote a fork.

———————————————————————————————————-

A few years after that, she stopped developing and distributing her software altogether, to focus on writing the grants.

Why? She said the clients kept asking for changes. 😂😂😂😂

————————————————————————————————————

Years later, after I finished my Bachelor's in Economics and landed a job in a logistics company in Philadelphia, I gravitated to software myself, and learned what we and every software company knows: the software is the equivalent of the printer, the professional services and customizations are the equivalent of the printer ink. One you practically give away, the other is where the real lucrative value is derived from: if every piece of software were suitable to solve all businesses’ needs out of the box, there is no business model nor competitive advantage. Many functional areas are similar, the differences are in their support for business functions in which they compete with other market players. It is the engine for customizations that then lock software customers into certain software, true enmeshment, and into services and support for those customizations that support upgrade paths and future enhancements.

Thus, my mother had abandoned parts of her business at the very moment it likely could have justified scaling up.

Those who have vibe-coded something would do well to learn about what happens after you ship your initial software. Vibe coding something sitting on a server, with some static pages or implementations and some UX forms or dashboards, connecting to a distributed server to fetch, store, process, and present feels miles ahead of desktop databases processing database files, modest form interfaces, and processing and tracking email campaigns, but the lessons my mother learned may serve some well today.

———————————————————————————————————

Lessons for Today’s Vibe Coders

1. Distribution and Migration

When you change the software, how will you distribute the new version? Will customers receive updates automatically, or will each installation need to be upgraded?

Will existing data need to be migrated to support new functionality or changed data structures? How will you test the migration, and what happens if it fails?

2. Integration

How will the software integrate with the other systems, services, and workflows used by your customers?

A useful application rarely exists in isolation. It may need to exchange data with accounting systems, identity providers, payment services, email platforms, CRMs, reporting tools, or internal databases. Each integration creates another dependency to design, test, monitor, and maintain.

3. Software Development Lifecycle and Change Management

How will you manage change within your own development process?

For example:

• How will you separate development, testing, staging, and production?

• How will you manage multiple versions?

• How will you handle features that are in development while the current version remains live?

• How will you roll back a release that causes problems?

• How will you know which version a customer is running?

The first version may be simple. Maintaining several versions in different states is where complexity begins.

4. Support and Enhancement Requests

Who will respond when customers have questions, report bugs, request enhancements, or need help understanding the software?

Support becomes part of the product. You need a way to:

• Capture requests

• Reproduce problems

• Prioritize enhancements

• Communicate status

• Distinguish bugs from feature requests

• Decide what belongs in the core product and what becomes customization

My mother discovered this part firsthand: once people depend on software, every “small change” becomes a product decision.

5. Tool, Vendor, and Version Dependencies

What parts of your application depend on a specific tool, vendor, software version, model, API, or AI capability?

Consider both development-time and runtime dependencies:

• What happens when a vendor changes an API?

• What happens when a software version is deprecated?

• Can you replace the component without rebuilding the application?

• Are your agentic or workflow functions dependent on a particular model?

• How stable are the vendor’s pricing and usage limits?

• What happens if the cost of an API call increases substantially?

• Do you have monitoring, fallback behavior, and an exit strategy?

A prototype can appear inexpensive because the underlying tools are free, discounted, or in beta. The economics may look very different once customers depend on the application and usage grows.