Before You Buy Another Salesforce Add-On, Read This

I have a Computer Engineering degree. I am technical. I also had not written code in years, and I did not touch the code for this application.

I did the engineering. An agentic coding platform did the coding.

That distinction is important.

This started as an executive requirement

This was not a random side project I dreamed up because I wanted a prettier dashboard. It was an executive requirement and a direct ask from my CEO.

Before this application, I was trying to do the job with a bunch of spreadsheets. They were manual, they were painful to maintain, and they never quite captured the vision we had for how we wanted to operate the business. Every new question meant another tab, another formula, or another spreadsheet that only one person fully understood.

We needed an actual operating model.

Salesforce already contained a lot of the source data, but Salesforce did not give us the application we wanted. We needed our revenue model, forecasts, scenarios, customer concentration, channel performance, and the questions we ask every week in one place.

Our operating model pulls Salesforce data through a read-only connection and combines it with our operating assumptions. We can evaluate scenarios, examine monthly recurring revenue, track ARR movement, inspect customer concentration, analyze channels, and drill into the records behind the numbers.

This is not a collection of pictures someone exports before a meeting. It understands our definitions and applies our business logic. It distinguishes actuals from forecasts. It lets us change assumptions and see what happens.

Salesforce is still the system of record. Harper is where we built the application we actually needed.

Explore the reference architecture: Custom Salesforce Data Applications.

‍

I did the engineering, not the coding.

Agentic coding changes what “building software” means for someone like me.

I understood the problem. I designed the solution. I defined the data sources, calculations, workflows, security boundaries, and expected behavior, and I reviewed the tests that proved it was correct.

The agentic coding platform translated that engineering into code.

It did not magically understand our business. It did not decide how ARR should move across a bridge or which assumptions belong in a forecast. Those decisions still required judgment, domain knowledge, and a lot of review.

What it did was remove the part where I had to spend months relearning frameworks, writing boilerplate, and connecting a pile of infrastructure products before I could test whether the idea even worked.

I built this in the background while still doing the rest of my job.

The Git history is almost comical. The first recorded commit, on April 2, already contained 51 files and 8,090 lines. By the end of that day, the repository had 28 commits covering forecasting, an ARR bridge, production deployment tooling, authentication, filtering, documentation, CSV and PDF exports, and opportunity-level drill-downs.

Today, the project has more than 500 commits.

My recollection is that the first useful production version took a couple of days. Not a quarter. Not a six-month implementation. Not a statement of work.

For this problem, buying Tableau would have been a joke

I know some people love Tableau. That is fine.

For this use case, buying more Tableau would have been a joke.

A dashboard can show me a number. I needed an application that could explain where the number came from, let me change an assumption, recalculate the model, and take me to the underlying records.

Those are not the same thing.

Salesforce is already stupid expensive. Its answer to many problems seems to be another product, another license, and another annual contract. Tableau Cloud currently lists Standard starting at $15 per user per month and Enterprise at $35, billed annually; Cloud+ and Tableau+ require contacting sales. Every deployment still requires at least one Creator.

Source: https://www.tableau.com/pricing/cloud

Salesforce lists Revenue Intelligence at $220 per user per month, or $250 per user per month with Tableau, billed annually. Ten users at the lower price would be $26,400 per year before anyone implements or maintains anything.

Source: https://www.salesforce.com/sales/revenue-intelligence/pricing/

Harper Fabric has a free starting tier, and production Scale pricing currently begins at $84 per month.

Source: https://www.harper.fast/pricing

Agentic coding platforms are also inexpensive by enterprise-software standards. As one public example, Claude’s individual Pro plan includes Claude Code for $20 per month when billed monthly, with higher-usage plans available.

Source: https://claude.com/pricing

These products are not perfectly interchangeable, and I am not pretending software licenses are the entire cost of building an application. You still need someone who understands the business. You still need testing, review, and ongoing ownership.

But come on. The economic difference is ridiculous.

You can prototype on Harper for free. A small production deployment starts at $84 per month. Add an agentic coding platform and one technical businessperson can build a purpose-specific application without beginning with a large software and consulting commitment.

The architecture is smaller because Harper does more

A traditional custom reporting application can quickly turn into an integration service, a scheduler, a database, a cache, an API server, an authentication layer, an application host, and a BI tool.

Every one of those products may be perfectly good on its own. That is not the point. The point is that I would have to buy, connect, secure, deploy, and maintain all of them just to answer questions about my own business.

Harper Fabric gave us one place for the synchronized data, application logic, APIs, scheduled work, access control, session handling, and user interface.

Fewer moving pieces mean fewer integrations to maintain, fewer things to break, and a much shorter path between “I need this” and “here it is.”

This is what agentic development is actually good at

The interesting part of agentic development is not that an AI can generate code. We have all seen generated code.

The interesting part is that someone who understands a business problem can now engineer a real solution without personally typing every implementation detail.

That does not eliminate engineering. In my experience, it makes the engineering decisions more important.

You still have to define the problem correctly. You still need guardrails. You need to know which systems can be read, which systems can be written, how authentication works, how calculations are validated, and what must never happen during a deployment.

The agent can write code. It cannot own the consequences.

In our case, Salesforce access is read-only. Production deployment is explicitly controlled. Revenue calculations have tests. Synthetic data is used for public demonstrations. Those constraints are part of the application, not cleanup work performed after the fun part is finished.

Build the application your business needs

If your team has valuable data in Salesforce and the proposed next step is another expensive analytics upsell, I would challenge that assumption.

Keep Salesforce as the system of record.

Use Harper Fabric to turn the data into a purpose-built application.

Use an agentic coding platform to handle the implementation while you focus on the architecture, definitions, controls, and experience.

Personally, I find that a lot more interesting than buying another dashboard.

Start building with Harper Fabric: https://fabric.harper.fast/

‍