Three years ago, when we started working on the ideas behind 1Logtech, our mission was to allow domain experts (the “citizens”) to build logistics solutions. Our first use case was integrations, as it is a particularly painful process in today’s logistics solutions.
The assumption was that by removing development from the construction of the integration, the business users who know how these systems work and what the data means, do not have to translate this knowledge to developers, who are usually not very interested in the tedious details of the domain. This would greatly simplify these projects and reduce multi-department integration project teams down to one or two business users.
At 1Logtech, we have had great success with this approach and have seen exponential gains in time savings and reduced resources in building these solutions. While we were very excited about our progress, what we didn’t expect was the game-changing effect on how we run and grow our own business.
When we started, we knew that we would have to build out the initial implementations, and it was important for us to use our own tools. So, we hired a guy who had done implementations at a TMS (Transportation Management System) company and thus was our internal domain expert. The plan was to have him be the main ‘developer’ for our customer projects, while having no programming experience.
This has gone far better than anticipated. Our projects have been successful, our customers are very happy, and our resources are not overloaded. Of course, the tool is not perfect, and we continually improve the product as we find areas where the business users struggle.
As a startup company, having a successful product and happy customers is critical, but there are other factors critical to growing the business. And growing the business is, of course, the primary goal of the investors.
In a recent board meeting we were reviewing our recent sales and pipeline, which is continually growing, and one board member asked if we would be able to handle large numbers of new implementations. This has been a concern for our executives as well. From their previous experience, implementations are long and painful, requiring a lot of resources which quickly get overwhelmed. We see this with our customers’ IT teams not being able to keep up with the demand. If integrations require development (as most projects do, even when using tools like Cleo and Boomi), one can understand this backlog.
When developers are required, scaling is limited to the size of your developer team. These are finite resources, not easily expanded, and not cheap. When you remove development from projects, the game is changed. At 1LogTech, since implementations are not bound by development, we can scale our concurrent implementations in the following way:
#2 works for us because we can bring in a domain expert (citizen developer) and train them in a couple of days. This is one of the unexpected benefits of citizen-based programming, and illustrates how lowering the bar in terms of technical skills is a tremendous boon to building solutions:
“We can scale our business using a fraction of the resources that traditional software vendors require”
Cost effective scaling of a software business is critical to surviving in today’s tough logistics market. Without it, you’ll burn through your cash as you struggle to build ARR.
Additionally for startups, customer service is equally important. When you are a new player in a market, each new customer is critical to your success, and you cannot afford to lose any. Customer service is key to that retention. Typically, new customers have access to the leadership team of a startup and they get very personal, white-glove treatment. Of course, this level of executive involvement can’t last forever, but ideally all customers should have that same level of personal, white-glove service as the company grows. That is typically very hard to do.
Recently, we were talking to a prospect about replacing a visibility tool. They were a very early adopter of the tool, and as such had access to their system architect, and a premiere level of service. Now, many years later, the level of service has degraded so much so that they don’t even bother submitting tickets anymore and just live with the problems. That is a sad story that we cannot afford to repeat.
Our company is young, and our execs are engaged in many projects, but we are starting to see the benefits of citizen-based programming in our level of customer service. Our customers deal directly with our domain experts, who either built the implementation or assisted the customer in building it. There is no intermediate layer that has to escalate to someone who can actually help the customer with their specific problem.
More importantly, citizen-based programming is inherently supportive of self-service. The skill level of our internal domain experts implementing solutions is the same skill level of the customer. As customers learn the system and start building their own solutions, automated support via AI agents can assist the user in building and troubleshooting integrations, similar to how a developer uses an AI coding bot. Our AI agents know the context of the user’s solution and have access to our knowledge base of using the tool to solve specific problems.
By using our own tools, our domain experts will be using these same bots to help them build solutions, and from their experience we will continually train the model and improve the agents’ usefulness. This is very powerful and points out the second surprising benefit of citizen-based programming.
“As our business grows, we can continue to provide personalized, white-glove service to ALL our customers, in a very cost-effective way”
In conclusion, the benefits of citizen-based programming are game-changing for software vendors. All vendors struggle with the time and cost of implementations, amid constant market pressure to reduce these costs. Maintaining a high level of customer service adds to that cost.
To solve this problem, many vendors are leaning into the latest silver bullet – AI coding. While AI can help programmers be more efficient, the 10X factor being claimed is a gross exaggeration. While improving programmer productivity is fine, it won’t move the needle for software vendors struggling to keep up with customer demands and implementations. The root of the problem is not programmer productivity, but the lack of domain knowledge in the people building the solution.
Citizen-based programming leverages the domain knowledge of the business user and is the only way to get exponential improvement in servicing your customers, for both implementations and support.
Contact 1Logtech at info@1logtech.com or www.1logtech.com to learn more.