One of the cool things about working with DABL is that I get to work with companies of all sizes and cultures who are trying to convince their customers that they have a decent idea for something.

For example, I just got out of a three-day workshop between DA, a well-known $1 billion company, and an even better-known global consultancy. 

We were all there to develop an idea to transform another industry using DLT. The workshop included subject matter experts, project managers, business analysts, experts in design methodology, and the usual menagerie of tech peeps. We ordered lunch, put things on stickies and affixed them to flip charts. We talked value-prop, tech-stack, services, network-effect, and roadmap. 

Those three days and their prep cost hundreds of thousands in consulting dollars, but we managed to build consensus around the thing we wanted to build, to put in front of CEOs to get their buy-in. 

In contrast, the week before that, an entrepreneur came in with a concept for an international charitable microfinance platform. The idea was very much in its early stages — he said his developer was only available on weekends because “day job” — so we spent about an hour whiteboarding the workflows and discussing potential tech problems and solutions. 

Eventually, this entrepreneur will need buy-in from various different types of organizations who must participate in the endeavor, including financial institutions and NGOs in different regulatory regimes.

While the two endeavors are starting in very different places, they share an identical next step: Go out, pitch the idea, and win partner and user support. 

Both enterprises now have a choice of where they will spend their effort to make this pitch compelling. 

Obviously, the best way to show your client that you have something is ... 

… To show that you have something. The best option — unshackled from material concerns like time and money — is to build the product, demo it, and revise it to meet your client where they’re at. 

Also obviously, people rarely do this. Instead — and this is the instinct of pretty much every consultancy, ever — is to burn hours building slideware. This’ll spell out in prose the goal of the software, the workflows (who doesn’t love UML?). Bonus points if you can add some clever phrasing about “disruption.” 

The time and dollar cost of slideware is well known. 

In the case of the first project I cited, the consultancy was very clear: The pitch deck would cost somewhere in the low five figures — and that was for a simple collection of words on slides, maybe with a diagram or two. (It’s not unusual for the cost of decks to rise to six figures for some swanky visuals and consultantese.) 

There is variance in the quality of slideware, and the best decks can compel a decision to invest. However, slideware is limited to abstract ideas. It demonstrates nothing concrete, which inevitably makes it harder to create an emotional connection with the prospective partner reviewing it. 

People understand slideware’s shortcomings, but they fear the cost of actually starting the development work, or committing to showing real artifacts to their potential partners. 

They think that the cost of a useful artifact that can be demoed is greater than the cost of building a pitch deck — both in terms of time and money. 

I disagree.

In both cases mentioned above, we proposed that a single engineer, in the company of somebody who knows the business case, could develop the salient part of their application within a week. And frankly, most of that week would be to learn Daml; an experienced Daml developer could design both projects’ happy paths in less than two days. 

They could then deploy this to project:DABL, which takes about five minutes, and have something to demo using DABL’s console.

They could also add a front end using a tool like React or Angular. (Note that there’s no intermediate layer to worry about between DABL and the front end, since DABL provides all the REST endpoints).

Anecdotally, working on other projects, building an entire back end using Daml deployed on DABL takes about half as long as writing a React front end. 

Altogether, we’ve found this less resource-intensive than developing slideware. 

The Daml Way has a lot in common with creating a functional prototype in Agile development, with one important difference.

Unlike a prototype, your first rev in Daml is already an elegant and functional steel thread for the solution you’ll ship. Instead of a “paper prototype” tediously created in PPT, your audience can see — and try out — the sapling of the real product.

If they suggest aspects of your idea are misguided or inadequate, you can revise and enhance the actual code instead of spending your time reworking a deck. 

To see an example of the design process, consider this whimsical application my colleague Anthony built upon joining our company. He spent about 20 hours learning Daml and about 20 minutes on the actual Daml code.