Application development to a fixed price, fast - sounds like wizardry

Chief Wizard? It is not often that one meets someone who adopts that as a job title as anything other than a bit of conference keynote whimsy. But for Sachin Dev Duggal it seems the correct way to refer his role at Engineer.ai:

Unless I’m talking to one of the partners and then I use the slightly more boring ‘CEO’ title so I get taken seriously.

There are, of course, thousands of start-ups emerging every day around the world, which raises the question of why this one should be worth any mention at all. There are a couple of reasons. One is that all those start-ups are based on what the founders feel is a good idea, and the second is that, increasingly, using IT is very likely to make a crucial difference in the success or failure of those businesses.

The downside of that, however, is that the majority of those founders will have little or no experience of working with or exploiting IT beyond using social media and playing Candy Crush. Yet the businesses they are starting may well be based on good ideas that only require the necessary skills to build the required applications to make them work.

That is the space Engineer.ai is pitching at and pitching in a new way. A core part of that pitch is Builder, an application development process it has recently introduced, which aims at providing (the potentially millions of) non-tech-savvy entrepreneurs with a way of getting their dreams turned into the reality of an application or three that achieves objectives.

No, it’s not a body shop

At one level the business model is quite straight forward, being based on the notion of building up a repository of previously built business-related software functions and components. This is then coupled with managed access to a team of developers that both exploit the contents of the repository and develop new components and links to meet the goals of the customer.

At first it is perhaps too easy to see this as a slightly different marketing front for a body-shop agency. But Duggal is very keen to bury that idea:

In a body shop the customer knows what they want. They are project managing. They are responsible for delivery. Now it’s anyone with an idea and the sophistication of the buyer has become less and less. There’s more of a consumer approach. Body shops sell time and materials but we don’t. We sell a price to get a product. We do it faster, you save money, and if we do it slower it’s our problem.

One part of the business model is, therefore, those functions and processes that are in the repository. He estimates that 60% of any application is common code and has already been built before. These have a price, obviously, but customers are not charged for `building them’ each time. So unlike a body shop, where selling person hours is important, the name of the game is to get applications built – and paid for – as quickly as possible.

This does, of course, mean that a typical 40% of each contract has to be fulfilled by real developers, yet the company does not employ any. Instead it has come to agreements with 60 or more applications development companies to have access to their developers, as individuals. Duggal claims the number available at the moment is some 20,000 individual developers, each of which has been tested and scored:

We know what they’re good at, what they’re bad at, every time they do work for us their score goes up and down. It’s mapped to their face so even if they move between dev shops we still know who they are and what their history is.

Each one is given a part of the job – often just a single function. And the customer never gets to talk to or work with any of them. As Duggal observes, it could be the case that there are six different engineers who work for six different companies in different time zones. Each one is given a specification, approval from their employer to do the job, and a timescale. In other words, Engineer.ai has found a way to tap into the `slack’ time that all fully employed developers can face.

When working for Engineer.ai, the developers work in a secure Docker container provided by the company. All the work is undertaken within the container, with the necessary resources provided. Copying and pasting in and out of it is not possible, so full isolation and security is maintained.

They also work to two options on payment. ‘Spot rate’ is cheaper, but allows for their employer to pull them back with 24 hours’ notice. It is the ‘one-off’ price. ‘Reserve rate’ covers the need for on-going availability, for example with what he calls ‘upgrade insurance’. This covers inevitable upgrades such as when a third party API is changed and the application stops working. Duggal explains:

In our case, users pay the insurance and keep getting the new blocks being shipped to them and integrated into the app continuously, so they don’t have to worry about it.

What lies behind this is something which could be at least an interesting curiosity in the way of managing the mapping of disparate customer needs against available human resources while meeting tight price constraints and time deadlines. It could, however, end up being a pan-industry management tool for a wide range of project management services.

It’s not magic, it’s AI

The key underpinning to Builder is an AI tool specifically for managing the preparation of the specification of both the overall job and its individual components, including what comes from the repository and what is new work. It also does the project management of working with those individual developers doing the new work, and the pricing of the whole job.

It is also the primary customer interface to Builder and, depending upon the application the customer requires, it is the only contact, with details of the application requirements being gathered through an AI-driven online Q&A approach. There is also what the company calls ‘human-assisted AI’ for customers with more complex requirements.

Customers write a minimum description, which then goes through a lexicon analysis. This identifies words that have follow-up questions. Finally, the description is compared, using NLP, to the 20,000-plus descriptions the company already has. It then computes the score for how complicated that feature set is likely to be. Duggal claims this system gets the specification and pricing right 90% of the time.

Builder is the company’s second product. The first is a cloud services operation, and the idea is that the start-ups will run the developed applications, and the rest of their business as they, hopefully, grow on the cloud service provided, as SaaS. That gives the company what Duggal sees as a three-part agenda: the Builder app development process, the cloud service on which to run, and the combination to give customers a sense of assurance that there is both the scope and support resources for their businesses to grow and develop.

The cloud service is also modelled on the idea of exploiting excess service capacity owned by others. So the company does not provide its own hosting services but buys excess capacity from AWS, Microsoft Azure and now two other service providers.

The revenue is in the insurance and the recurring fees on the hosting and so on. And even with that it’s not its own hosting. It buys the excess capacity from AWS, Azure and now two other unnamed service providers. That allows them to utilise available large capacity services by multi-tenanting multiple small loads on them, says Duggal:

We have the ability, using algorithms, to find inefficiency of usage among our customers. We have 3,500 customers, so let’s say there’s 100 of them using a C1 server. That is the wrong way to buy a C1. What we should be buying is ten C10s because it’s cheaper, and we can break them into C1s while giving everyone individual secure private accounts. We’ve got a learning algorithm that looks at it like a portfolio so we’re able to see how that capacity is going to change over time. Then it makes forward purchase decisions on Amazon and Azure for two or three years capacity. When it does that, it gets a giant discount.

The customers also get a `discount’ depending on how much of the code needed is unique to their application. That is what they are paying for. So even if they are the first to identify a new routine, if it has potential for extensive re-use that will become part of the Engineer.ai code repository. Anything that is unique to a customer’s business is their IP is not the company’s.

My take

There are two ways of viewing this development from Engineer.ai. One is that an application development service, coupled with running cloud service provision, for a fixed price, should be of immediate interest to all start-ups, not least because the AI underpinning should mean in most cases that a tech-savviness quotient of zero should no longer be a hindrance to getting tailored IT services running. In addition, although the primary target for now is start-ups looking to do mobile apps, Duggal is well aware that major enterprises may have, say, 10 major $1 million-plus development projects a year, they also have thousands of $50k projects as well. They are a longer term target.

But the other way to look at this squarely at the AI – why is it being used, what is it doing, and how is it doing the job. Somewhere in here is, potentially, the guts of a management model for a huge range of project management related tasks, and if the company has it all suitably knotted up in patents this could end up a ‘nice little earner’ well out in to the future.