1. 26 / 10 / 2016
+32 (474) 97.26.80
info@locotalk.com
Ter Borcht 7, Brasschaat, Belgium
LOCOTALK
PROUDLY PRESENTING
Locotalk's mission is to democratize state-of-the-art business software. Currently, the value unlocked by the digital
revolution is primarily captured by large tech corporations. The rest of us are left behind because powerful IT solutions
are out of reach. Handling data and code, the raw materials of this new economy, is simply too hard and too expensive.
The unique combination of a low-code JavaScript application platform and a semantic graph database, allows Locotalk
to offer affordable integrated business applications to every company, regardless of size or expertise. We enable
knowledge workers to customize and build applications themselves, in a declarative way, without needing any
programming expertise. Locotalk ultimately strives to become the leading business operating system in the cloud for
modern companies participating in the data-driven economy.
Mission
1. Introduction
We are in the midst of a profound technological shift in which software
is disrupting virtually every industry. Gartner refers to this shift as the
“Nexus of Forces”. Technology innovations in social, mobile, cloud and
information computing are converging into a mutually reinforcing and
interdependent force, fueled by massive consumer adoption of
innovative apps and services.
As a consequence, organizations are fundamentally transforming how
they operate, interact with customers and go to market. The challenge
for a modern company is to keep up with the accelerating pace of
change to effectively support the business in delivering the ultimate
customer experience and staying ahead of competition.
In the digital enterprise era, “every company is becoming a software
company”. This requires a radically different approach to IT. A new style
of applications that are focused on engaging customers, empowering
employees and improving business operations is emerging.
In contrast to large transactional backbones like ERP and vertical cloud
services, software applications that power the digital enterprise are
rapidly built, seamlessly deployed and easily changed in response to
evolving needs. Close collaboration between business and IT to design
apps that are actually fit for purpose is critical.
Locotalk is a distinct player in this emerging enterprise app-Platform-
as-a-Service market. This whitepaper provides an introduction to
Locotalk’s unique combination of a low-code JavaScript application
platform with a distributed semantic graph database. It explains how
Locotalk enables business & IT to build powerful applications together,
simply by combining and assembling essential software lego-blocks in
a declarative way, as opposed to handwriting application code.
This whitepaper is targeted at tech-savvy investors, solution architects
and CTOs who wish to obtain a thorough understanding of the
Locotalk platform.
Digital Revolution
2. Architecture vision
Locotalk exists to enable companies to build, integrate, deploy and
maintain web and mobile applications faster and with better results,
effectively reducing time to value. We architected a low-code
application platform that’s entirely focused on our mission to help
customers achieve that goal.
In 2006 we started our quest to build the perfect platform for rapid
application development. With a small, talented and focused team, we
came up with a first iteration of the platform, built on top of an industry-
standard SQL/C#/.NET stack. The results were not pretty.
Our first customer went live. We delivered exactly what they requested:
a responsive website with E-commerce functionality, a 2-directional API
integration with their back-end ordering system and a customer portal.
Yet, it turned out that our developers kept being involved in seemingly
small changes and feature requests. The customer wanted a different
workflow, a data model change, a UI tweak and everytime it would
require developers, developers, developers.
Discovering the problem
1Locotalk | whitepaper

2. We didn't want to become yet another software shop, selling
developer-hours for custom work, so we went looking for answers. Our
fundamental breakthrough was the realization that we had bumped
into an intrinsic limitation of the traditional software development
stack. It was time for a paradigm shift. A new way of looking at software.
One that shifts application development away from handwriting code,
to composing applications from reusable software building blocks.
The software development cycle today involves three stages. A real
world concept is modeled into a database scheme, code is written by
developers to make that data come alive in an application, and the
user interacts with it. So where do all those dollars and man-hours go?
Spoiler, they’re dissipated in the friction between user, code, model,
and the real world:
Eliminating friction
We are convinced that the only way to fix this broken development
cycle and to ultimately democratize great business software, is to get
rid of all sources of friction. Anything else is just a duct tape solution.
Friction 1: WORLD MODEL
It all starts with requirements gathering. The client explains a real world
situation and a set of requirements, which a software analyst translates
into a UML (Unified Modeling Language) diagram. UML is a fantastic,
visual tool for working with entities and relationships that are pretty
much a 1-on-1 mapping of reality.
From that moment on, things go downhill. Most databases are really
opinionated about the way they store data. SQL insists on mapping
everything to tables and columns, which is not how people percieve
the world of information around them. Furthermore, many-to-many
relationships in a relational data model require separate junction
tables, leaving it up to the analyst to decide how far to go with
normalization. In other words the analyst has to decide which parts of
the table might be better split-off so that they can be reused later on.
Example with UserPermissions as a junction table, an artefact needed to
store many-to-many relationships in SQL
Another cause of friction is that traditional databases like SQL require
tables to be defined by the developer or DB-admin, using some
separate tool like a management console. If a new type of data is
required by the user, developers are in the loop. Friction not only
means $$$ and developer man-hours, but mostly using developers for
low-profile maintenance-style jobs. Additionally, SQL databases are
typically hard to install & maintain, they have limited scale-out facilities,
and they typically have narrow device support.
But why is modeling such a big deal in the first place? Well, here's an
idea of the types of data we expect to deal with in Locotalk:
As opposed to Facebook, Twitter, Salesforce, ZenDesk and other
verticals, Locotalk's strength lies in its horizontal structure, integrating
all possible types of data. Why? Because the era of the silo must come
to an end. The business user demands it.
The obvious next step is to follow the path of NoSQL, which grew out
of the need to fix most of the problems brought on by relational
databases. Hugely popular sites are using NoSQL document stores, like
MongoDB. Both the biggest strength and weakness of document
stores, is that they promote denormalization. Instead of using separate
tables, data is stored as self-contained hierarchical structures, having
almost the same shape as how the data will be represented to the user.
Now, this may be fine if you're dealing with vertical apps — storing
tweets, likes or comments — but for an open horizontal platform
needing to support every possible concept a user can think of,
document stores are a big no-no. Denormalization is fine at the cache
level, but at the canonical storage level it's a nightmare for anything
other than hyper vertical scenarios.
Linked data to the rescue
The solution came from an unexpected and relatively unknown corner
of NoSQL land: semantic graph databases. It’s one of many clever
concepts promoted by the W3C, that has found its way into the core of
Locotalk’s architecture. It shouldn’t come as a surprise that the missing
2Locotalk | whitepaper

3. piece of our data puzzle comes from the hand of the creator of the
world wide web himself: Sir Tim Berners-Lee.
In his seminal TED talk in February 2009, he did an almost emotional
plea for web creators to unleash not just the HTML representation of
their data, but to also provide APIs to access the raw unadulterated
data, fueling most websites. The standard format he proposes for
sharing this information is called semantic linked data. The idea is
both simple and revolutionary. Every single piece of information in the
world can be represented by a set of triples. A triple has the same
ingredients as the sentences we speak every day. Namely:
[ subject, predicate, object ]
There are databases capable of natively storing data in this format.
They’re called Semantic Graph Databases or Triple Stores. It's
surprising that this concept has yet to go mainstream, given its many
advantages:
• Full normalization: every entity, property, and relationship
has a URI: owns, livesIn, madeBy. These are qualified
within a domain making them globally unique. Being fully
normalized out of the box, the data analyst is unburdened.
No need for clairvoyance or frequent refactoring.
• No need to "shoehorn" reality into the model, introducing
artefacts and simplifications that cause more harm than
good in the long run. The real world is most elegantly
mapped to a graph model.
• No need for database artefacts such as junction tables. If
John owns more than one car, additional owns triples can
be added: no need to change the whole database schema.
• Semantic data is the fuel for AI and deep learning, one of
the technologies taking the industry by storm (and by
surprise). The linked data of the semantic web happens to
be the native language of machine learning algorithms, a
concept called reasoning or inference.
• There are tons of high quality vocabularies available in
semantic format (RDFS/OWL), modeling a wide range of
industry standard concepts: social graphs, e-commerce,
comments, ratings, etc.
• UML class diagrams map 1-on-1 to semantic building blocks
and can be seen as a window to the data. If the data
changes, the UML view changes automatically. No more
diagrams you can't trust because they might be out of date.
• Metadata (the types/classes) is data too. No more schism
between DML (Data Manipulation Language) and DDL
(Data Definition Language). It's all the same. The citizen
developer gains control over areas that used to be
developer-only.
• Memory-efficient: all property triples are fully typed and
binary encoded. A triple of type "Date" will only take up the
minimum required bits needed to store it.
• The data is stored efficiently in a sparse way. Non-existing
properties and relationships don't create any triples, which
means they don’t take up any space, unlike in SQL tables.
Production ready semantic graph databases appear to be rare, and still
seem to be stuck in the academic world. The ones available of the shelf
were too limiting so we decided to bite the bullet and build our own:
LocoDB.
LocoDB is truly multi-platform triple store and runs on anything from a
72-core Xeon server, down to a Raspberry Pi. Its footprint is just 890
kilobytes. It supports transactions, mirroring for master-slave operation
and backups. We also taught LocoDB to stritcly enforce semantic
schemas. It includes support for distributed, inverse, and nested
queries. Optimistic locking and indexing are in the works.
Furthermore, using an advanced semantic concept called reification,
every single property in LocoDB can be localized. This means
applications never need to worry about this. It's built right in at the data
layer. Since everything is data in Locotalk, including our applications,
localization is effortless. This contrasts the broken localization support
in most established frameworks. If you've ever localized an application,
and tried to keep it that way, while constantly adding and changing
features, you'll greatly appreciate this feature.
Let's take a look at why linked data doesn't appear to be happening at
the moment.
In order to provide a semantic version of the underlying data that fuels
a website, the semantics will have to come from somewhere. Right
now, for the majority of sites on the Internet, semantics are scattered
across the data model (50%), the code (30%) and the head of the
developer building the site (20%).
Because there’s no raw semantic data available, Google turned to
something called RDFa. This is a way for web developers to embed
semantic data inside the actual HTML page. This allows search engines
to readily recognize things like ratings, prices and stock availability:
What’s holding linked data back?
3Locotalk | whitepaper

4. To get this result the site developer somehow needs to add the
semantics to the HTML, as follows:
The problem here is that things work backwards. Semantics get thrown
away at the input stage, where you’ve defined the data model. It
subsequently requires a developer or designer to readd the semantics
in the presentation layer, where you should only be dealing with
formatting and styling.
This process looks a bit like a factory making
candies of all kinds of colors, throwing them all
on one big heap, and then hiring staff to sort
that heap into separate colors for packaging. It
makes sense nobody is doing this and it explains
why most open data initiatives are restricted to
governments and public organizations.
The example above shows how semantics get lost in translation, in the
context of a simple website. That said, it’s representative for how
semantics get treated in any traditional business software or modern
cloud application. When software is built on a traditional stack, you
inevitably lose semantics shipping data between database, server, and
client. The result is that you’ll never achieve complete integration
between applications nor across organizational boundaries.
Locotalk captures semantics right at the input stage and never lets
them go. We ensure semantics are available throughout the entire
platform: database, server, client. This is the low friction path to a truly
open data web. There's no extra work to be done. Just make sure you
hold on to the semantics, every step of the way.
Friction 2: MODEL CODE
LocoTalk has its foundations in a large array of industry-standard
design patterns, most notably Object Oriented Programming (OOP)
and Model Driven Architecture (MDA). We’ve adopted these patterns
to combat friction between the data model and the application code:
• SQL works with tables, OOP with classes and objects.
• Server code = C#/Java/PHP, client code = JavaScript.
• Data validation needs to implemented multiple times.
At the client (for fast UI response), at the server (for
security), and at the database (for consistency).
Sure, for each of these sources of friction, there are existing solutions:
• ORM (Object Relational Mapping) tools can translate
SQL tables into objects and vice versa.
• Code that needs to run on both the server and the
client can be written twice, in different languages.
It can all be done, and boy have we tried. Just add more duct tape and
more developers.
Was it serendipity or just plain luck, fact is that in 2009, Ryan Dahl came
up with the audacious plan to make JavaScript run on the server.
Node.js is a server-side JavaScript platform for building network
applications, featuring an event-driven, nonblocking I/O model. It’s an
extremely lightweight and efficient alternative to the resource-heavy
multi-threaded frameworks that dominated the scene at that time.
This fabulous technology paved the way for what we now call universal
JavaScript applications. In entails that JavaScript code can run across
the entire development stack: from client to server, and in some cases
— like MongoDB — even in the database. The technology was really
young and experimental at the time, but we jumped right on the
Node.js bandwagon. History proved us right.
So is there any friction left? Well, obviously there's still the issue of
LocoDB speaking the semantic language of triples, while it's just plain
OO classes in JavaScript. How do you match them up? The answer was
just as obvious as it was tricky: make JavaScript talk triples as well.
If both code and database talk the exact same language, friction is a
thing of the past. We created LocoJS — a JavaScript framework of 50kB
(minified/zipped) sprinkling semantic magic on top of standard JS:
The framework defines regular JavaScript classes — Triple, Entity,
Property, Relationship — that form the DNA of the semantic world.
Everything else is built on top of this:
Above is an example of a triple, specifying the birthDate (predicate) of
John (subject) to be '2/2/1987' (object). When the triple arrives in the
JavaScript world, an instance of the JavaScript class "birthDate" is
created (or fully qualified: "locotalk.core.birthDate"), and its subject
and value are set appropriately.
4Locotalk | whitepaper

5. The Locotalk framework constructs the semantic "birthDate" class
behind the scene, as derived from "Property", which is itself derived
from "Triple". That's all there is to it. The dynamic character of
JavaScript is highly suited to this type of meta programming. Looking
at a subset of our earlier example, stripped down to just 4 triples:
The resulting JavaScript objects in LocoJS look like this:
The 4 boxes in the middle are JavaScript versions of the 4 triples. This
was the easy part. Of course, we can't expect developers to suddenly
start working directly with triples. It's perfectly possible to instantiate an
Entity class, along with some Triples. This would be the "Entity-centric"
way of working. In order to reduce the alien factor, the framework
creates facade (also called proxy) objects which hide the triples and
which look like regular classes themselves.
This means the developer can simply execute:
var p = new Person();
p.birthDate = '2/2/1987';
Behind the scenes low level entities and triples are created in a lazy
fashion. We consider this is as one of Locotalk’s greatest achievements:
being able to present a pure semantic layer to the developer as
regular OOP objects. That's what we mean with zero friction.
With this structure in place, dealing with data in your application code
is a breeze. Say you have a large component tree instantiated in the
browser or server, counting hundreds or thousands of entities and a
few nodes in this tree are modified (e.g. using data-binding with the
UI). Since triples have a "dirty" status, it's a trivial task to collect just
those triples that were modified and to persist those changes to the
database. It’s literally a single function call.
Mission accomplished: we got client and server to talk the same
language as our database. Semantic triples all the way baby!
Friction 3: USER CODE
There’s been a status quo for so long, most don't even realize it’s there:
• In developer land, programmers use development tools to
cook up the software. Eventually code is compiled and
deployed, to finally end up on a server so the user can
access the application. Whatever’s part of this process can’t
be influenced by a user. It's the program dude, deal with it.
• User land, on the other hand, is completely constrained by
what the application developer provisioned. Want to shuffle
some pages or forms around? Want to display items on a
geographic map instead of a table? Tough luck. Go back to
the developer and ask for it. There is a solution called a
CMS (Content Management System), but it's again limited
to the functionality its makers programmed into it.
Admittedly, it took us some time to realize this was a major cause of
friction. Remember, how we talked about our first customer, who
continuously asked for seemingly trivial changes, which always wound
up on our developer desk? Well, it turns out that this was caused by the
friction between the user and the application code.
We wondered: “What if everything was CMS?”
What if developers ate their own dogfood and
used the exact same tools at the disposal of
the user? What if there was no developer land
and user land, but just components and flow?
We went back to the drawing board, and built one seamless platform
without artificial boundaries between what a developer and a user can
do. Restrictions are only ever imposed through access rights, not by
design limitations.
The breakthrough came in the form of a book by J. Paul Morrison,
presenting a pattern called Flow Based Programming (FBP). The
author makes the comparison with electronics design, where designers
use standardized building blocks ("chips"), which are combined in
different ways to create new hardware systems. He wonders why
software development fails to achieve this powerful design paradigm
of reusing the same building blocks, but instead keeps reinventing the
same functionality over and over again.
5Locotalk | whitepaper

6. Locotalk came up with a powerful component and workflow system,
that’s lets you compose applications from basic software lego-blocks.
The yellow blocks at the top show a few simple components in a
graphical way, more or less how they'd be presented in a drag & drop
UI. The white boxes in the middle show their corresponding UML
instance representation. The black boxes at the bottom show the exact
same components, presented declaratively as XML.
Internally, all data is represented as semantic triples, stored in the
database, and exchanged as triples all the way to the client. So where
do we apply this flow pattern in LocoTalk? Well, everywhere:
• The server code responds to REST API requests by
instantiating corresponding flows, and executing them
asynchronously in its Node.js environment.
• The client code in the browser deals with hierarchies of
document components, driven by flow. Clicking a button
will show a popup panel if its onClick output pin is wired to
the show input pin of that panel.
• Flows can even be used indirectly at the database level. We
can use the mirroring connection of LocoDB to detect
certain events, like a new user registration, and fire off a
corresponding flow on a separate server, to send a
verification mail for example. This allows us to keep our
database implementation lean & mean, free from any
constructs such as triggers and stored procedures.
Hopefully you’re recognizing a pattern emerge here. We only ever
implement recurring concepts once, at the right place. They become
essential software building blocks, which we subsequently reuse ad
infinitum. Taking the DRY design pattern to the extreme, if you will.
When you create such highly reusable building blocks, one of the
added benefits is that after a given time, they’ll be thoroughly
debugged and optimized. The effort pays off tremendously in the long
run.
Now, flow is generally considered to be server technology, so what do
a front end web applications have to do with it? We've already covered
the fact that in Locotalk everything is data. This means software is data
as well. It makes sense that if you can model any aspect of our world,
the world of the programmer can be modeled as well. This is a key
concept of "Model Driven Architecture" (MDA).
In LocoTalk, web applications are a set of loosely coupled document
trees. They can represent a static document, a marketing site, or a
highly interactive web app. For us there’s no difference. To achieve this,
we defined all the building blocks that make up a page or an app, as
components. They’re modeled just like any other data type such as a
“Person” or “Product”. It made sense to use a popular and well known
document markup language as a DSL (Domain Specific Language) for
this: HTML.
We could’ve devised our own language, because it's just the way we
represent the page or app internally. It can be rendered in any desired
format. Our main target however is the browser, therefore HTML is the
perfect DSL, to make rendering to the DOM easy and efficient.
The same exercise was done for domains like CSS and SVG. All their
elements are modeled as components. “locotalk.svg.Circle” is a
component, by default rendering as an SVG Circle element in the
browser.
The document tree that makes up the page or app is essentially an
entity tree stored in the database. Its nodes are components
corresponding to HTML elements, combined with other functional
components that encode the application’s business logic. As all
components are just data, they can travel freely to/from the database,
no conversion needed. They’re just triples being moved over the wire.
There are a number of standards to express semantic data, such as N3
and Turtle. We created the TripX format (Triple Xchange), designed in
such a way that it has a low alien factor for most web developers.
There's a JSON and an XML variant. TripX can easily be converted to/
from N3, Turtle or any other representation. Here's how the above
document tree looks in TripX (XML variant):
Looks a lot like HTML, doesn't it? Make no mistake though, it's not. It
expresses a set of triples, forming a hierarchical document tree, which
just happens to use HTML as a DSL. Here's the JSON version:
It's a little more verbose than the XML version, which owes its elegance
to the content-property pattern borrowed from XAML. The JSON
version on the other hand, exposes the semantic internals fairly well.
Once arrived at the client, the document component tree can be
rendered. This happens by traversing the tree, and mounting view
objects on each of the document nodes. The default view for e.g. an
“Input” component will render straight to an HTML <input> element,
ready to be inserted in the DOM. More elaborate widget nodes will get
a view that is itself a new document tree, similar to "templates" in
traditional front-end frameworks.
6Locotalk | whitepaper

7. The result of this traversal is a corresponding tree of views that can be
considered to be a virtual DOM. It exists purely in JavaScript, but each
leaf node has its counterpart in the actual browser DOM. User
interactions are handled by flow. When a button is clicked or item is
dragged, actions are triggered in the DOM, depending on how the
components are wired together using binding. All of this is purely
declarative. No coding involved.
Working with such a 2-tier node/view mechanism allows us to render
documents in entirely different ways. The same document could for
example be rendered server-side as a PDF or as a plain-text document,
in the context of sending an automated email. Since document nodes
are components we can use binding for things like a "mail-merge".
Binding is native functionality in LocoTalk, i.e. not restricted to the UI.
This is a good time to point to the seemingly subtle but far reaching
difference with many popular low-code platforms. Most of them are
implemented on top of a traditional development stack (e.g. SQL/
C#/.NET). This results in models that are more or less "take it or leave
it". If the user wants to change or add some functionality, they're out of
luck due to the aforementioned user-code friction.
In Locotalk there is no such artificial boundary. All components are
constructed in the same declarative way, as they are themselves
composed into applications. The process is seamless. If an app
developer wants to create a very specific UI panel with hand-crafted
HTML and CSS, and insert some standard high level component at
some node inside, they can perfectly do this. The language of a single
<div> node is the same as that of an entire shopping cart component.
Conclusion
Locotalk recognizes three main sources of friction, standing in the way
of a true low-code platform. We’ve developed a unique combination of
technologies to remedy all three.
• LocoDB is a semantic graph database. It makes modeling
the real world easy and intuitive. It’s the ideal data store to
tackle the hard problem of application integration and
sharing data across organizational boundaries
• LocoJS is a JavaScript application framework that turns any
JS-runtime into a semantic environment. It allows seamless
exchange of triples with the LocoDB, which in turn
eliminates all friction between model and application code.
• LocoFlow is a workflow framework. It introduces
components and flows, which transforms application
development from handwriting code to composing
applications by chaining together software lego-blocks.
All friction is now gone. Data — both user data and code — flows freely
across all layers of the software stack. It starts with the data model,
which represents the user's world modeled as triples, stored in a native
triple store. A semantic JavaScript framework, speaking triples natively,
passes data to the client. The application’s business logic is built by
composing essential software components into intricate workflows.
Lastly, the data reveals itself to the user as a modern, responsive web
application or to external systems as a standard REST API.
The big breakthrough realized by Locotalk’s low-code application
platform is that it drastically reduces the amount of custom handwritten
code required to build, customize, extend, and maintain great business
software solutions.
7Locotalk | whitepaper

8. 3. Business model
Locotalk ultimately strives to become the leading business operating
system in the cloud for modern companies participating in today’s
data-driven economy. We’ve identified three phases en route to
reaching that goal.
Phase 1: agency
Initially, we’ll offer custom business software solutions as a run-of-the-
mill IT agency. Locotalk will target medium-size organizations (50-500
employees) and offer bespoke cloud business applications, tailored to
the client’s needs. We’ll outcompete competitors by offering more for
less, by leveraging our unique in-house technology. Projects are
expected on average to generate €50K in implementation fees and
€1000 / month in subscriptions fees.
The goal of this phase is first to prove the merit of the Locotalk
platform in a real business environment. The second goal is to reach
the break-even point, effectively making the company financially self-
sufficient. Lastly, the generated income (low-volume, high-margin) will
be used to get to the next phase of the business model
Phase 2: product
In the agency phase we’ll have proven the platform’s value proposition
at a small scale. We’ll also have a significant collection of rich software
building blocks at our disposal. In other words, the platform becomes
more powerful the more we use it. We’ll use those components to
develop and market an all-in-one cloud business software solution,
containing all the essential business apps (CRM, invoicing, inventory
management, E-commerce, CMS, and more). Competitors will be
outcompeted on breadth of scope, level of integration, ability to
customize & extend, and ultimately price.
Going from one phase to the next, we can afford to address lower ends
of the market, delivering the same great business software to more
companies, at lower cost. It will uniquely position us to service the
enormous untapped market of business software geared towards small
enterprises (<50 employees).
Phase 3: platform
We now shift our focus from improving the product (a suite of cloud
business applications) and delivering services (customizations and new
application development), to enabling others to build applications
themselves, atop the Locotalk platform. The business model becomes
subscription only.
All of our energy is devoted to optimizing the experience of building
applications. Through training, documentation, and evangelizing we’ll
attract agencies and knowledge workers to the platform.
4. Team
Erik Wijnen (CEO, sales, financing), Franky De Meyer (CTO,
architecture lead), Anthony Wijnen (CPO, product and design lead),
Carlos Manhaeghe (Core Engineer, database lead), Davor Sabljić
(Core Engineer, application lead), Johan Bonnaerens (Core Engineer,
architecture developer), Jakov Fustin (Core Engineer, application
developer), Nina Zubrinic (Core Engineer, application developer).
5. What we’re looking for
Approximately 70 man-years of software development have gone into
the project and it’s largely self-funded by the CEO and founder, Erik
Wijnen.
We are currently in the process of servicing our first beta customer, an
HR consulting firm from Ghent, Belgium. The spec includes a set of
back-office applications, a website to publish job vacancies, and a
portal for candidates to fill out personal questionnaires. We estimate 6
months are required to finalize this project and push it to production.
Today we are looking for new funding to continue Locotalk’s
development and commercialization. We’ve identified two possible
routes.
Option 1: investment
We are looking for a €500K convertible note. This would provide 12-18
months of runway, depending on the composition of the team, to
achieve the following essential milestones.
First, we’ll wrap up Locotalk’s core architecture to a point that it’s ready
for building and hosting production-grade applications. Secondly, we’ll
prove product-market fit based on a handful of custom business
software implementations. In other words, we’ll prove that scope,
integration, and flexibility are sought after by the market and
achievable by the platform. Finally, the funds will get us to profitability,
while in the agency phase.
The plan is to raise another round of funding in 12-18 months to turn
up the heat on product development, sales, and marketing, as we
enter the product phase.
Option 2: acquisition
Alternatively, we are looking for a strategic investor to acquire our
intellectual property and our team of experienced software
developers.
Our primary strength is software architecture development, while our
primary asset today is our technology. The primary goal is to get this
platform in the hands of as many companies as possible, improving the
lives of as many people as possible.
We realize that a larger organization, with the necessary resources and
experience bringing innovative cloud software solutions to the market
could help us achieve that goal faster.
We are looking for companies that aim to democratize great business
software. Or companies that have other applications in mind, that
would benefit from Locotalk’s unique combination of a low-code
JavaScript application platform and a distributed semantic triple store.
6. Contact
Erik Wijnen
Email: ew@locotalk.com
Phone: +32 (476) 40.99.89
Anthony Wijnen
Email: aw@locotalk.com
Phone: +32 (474) 97.28.60
8Locotalk | whitepaper