WupsE by Caesar

An Open Startup (OS) - WupsE Product

Concept

last-smile-delivery: A 21st century way of value creation for The Netherlands

Caesar de Keijzer

August 2022

1 A Short Why 2

1.1 What is WupsE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 What is wrong with a traditional startup for WupsE? . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Who will be the parties involved in WupsE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 WupsE details 5

2.1 Product motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Product description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Product speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Product justiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Initial design sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

In Devel opment Caesar de Keijzer

Intro

The emergence of the internet has given way to allowed for the production of open-source software and

hardware to proliferate. A distributed community gathers around a piece of code and continuously modiﬁes,

distributes, and improves upon it. The advantage of this allows for diverse knowledge sharing, adaptability,

and enhanced security.

People are free to share their ideas and contributions on the project and expand

upon the work done by the people before them.

Only very recently a new technology also appeared on the block. Building, and being build, on open-source

software, DAO’s have made their entrance.

DAO’s are shorthand for Decentralized Autonomous Organiza-

tion’s and similar to open-source software, are also community led. The rules of the organization are spelled

out in so called smart contracts which autonomously execute the decisions that the community agrees upon.

The code/rules of these smart contracts as well as voting mechanisms and member proposals are publicly

visible on the blockchain. There is no central governance, just a network of stakeholders working together

determined by set of encoded rules.

Decentralized development has been shown to be successful for reliable and safe software practices and un-

derstandable adoption. While DAO’s have a far less proven track record, the various emergent projects show

what it could be, and the vigorous work done on them deﬁnes the potential path forward.

That is why this author proposes the idea of an Open Startup, a: DAO run, open-source hardware startup

experiment organized around WhupsE, a last mile delivery robot running on bicycle lanes in the Netherlands.

Naturally, this leaves the reader with many questions. The following sections will hopefully clear away

those clouds and outline why this experiment in organizational structure and product development is worth

pursuing, at least here in the Netherlands. A short rundown on why this type of startup would be preferred

above a traditional startup structure is also provided.

In Development By: Caesar

That is why this author proposes the idea of an Open Startup, a: DAO run, open-source

hardware startup experiment organized around WhupsE, a last mile delivery robot running

on bicycle lanes in the Netherlands.

Naturally, this leaves the reader with many questions. The following sections will hopefully

clear away those clouds and outline why this experiment in organizational structure and

product development is worth pursuing, at least here in the Netherlands. A short rundown

on why this type of startup would be preferred above a traditional startup structure is also

provided.

A short why:

Startups come in various forms and sizes but are almost always about an idea or goal that a

founder would like to see changed and implemented in the world, ranging from the novel to

niche. With the often-associated goal to grow quickly and bring their innovative product to

market. This nearly always involves the experimental question: 

this question gets answered, the better for all parties

involved as well as the wider society. No major costs are incurred with quick failure, while

rapid success (see product/idea adoption) is generally a positive outcome and a

confirmation of the necessity of the product.

By creating a (tech)startup that is open for to the public domain, all essential stakeholders

can congregate quicker and easier around the product. Open-source development led the

way in this. People like to flock around interesting and engaging projects. Claiming a little

share in a successful product brings you kudos and accolades from your friends. Here is also

Formally creating a decentralized organization allows for the

quantification of the goals of the project, as well as managing the incentives for0 all the

many participants to reach this goal. Decentralizing the project allows for meritocratic

success of individual contributors as well as spreading of the involved risk. One person can

pick up where another has floundered.

Self-driving delivery robots appear a perfect fit for this type of startup. Seeing as the

development cycle requires involvement of more than a dozen parties and speedy

Figure 1: All individual parts of an Open Startup

1 A Short Why

Startups come in various forms and sizes but are almost always about an idea or goal that a founder would like

to see changed and implemented in the world, ranging from the novel to niche. With the often-associated goal

to grow quickly and bring their innovative product to market. This nearly always involves the experimental

question: ‘do people/corporations want what I’ve created?’. The faster this question gets answered, the better

https://www.unicef.org/innovation/media/206/file/Open%20Source%20Business%20Model.pdf

https://stanford-jblp.pubpub.org/pub/dao/release/1;https://aragon.org/

In Development Caesar de Keijzer

for all parties involved as well as the wider society. No major costs are incurred with quick failure, while rapid

success (see product/idea adoption) is generally a positive outcome and a conﬁrmation of the necessity of the

product.

By creating a (tech)startup that is open for to the public domain, all essential stakeholders can congre-

gate quicker and easier around the product. Open-source development led the way in this. People like to

ﬂock around interesting and engaging projects. Claiming a little share in a successful product brings you

kudos and accolades from your friends. Here is also where DAO’s come in. Formally creating a decentralized

organization allows for the quantiﬁcation of the goals of the project, as well as managing the incentives for0

all the many participants to reach this goal. Decentralizing the project allows for meritocratic success of

individual contributors as well as spreading of the involved risk. One person can pick up where another has

ﬂoundered

Self-driving delivery robots appear a perfect ﬁt for this type of startup. Seeing as the development cycle

requires involvement of more than a dozen parties and speedy deployment would suit all involved. With reg-

ulations being one of the major current hurdles, having both the software as well as hardware being open to

continuous review, problems are snuﬀed out on a rolling basis. Below one can ﬁnd a more detailed exploration

of WupsE as well as some technical speciﬁcations.

It is to be noted that this speciﬁc setup would not work for every startup. Decentralization requires strong

and additional communication as well as suﬀering from a lack of a ‘central motor’ for quick decision making.

1.1 What is WupsE?

WupsE is a small, cartoonish, electric, self-driving grocery delivery robot (operating in- between Nuro and

Amazon Scout) that is made to drive on bicycle lanes and enables an eﬃcient last-mile-delivery service. In

Dutch, it could be described as a self-driving ”bakﬁets”. It is large enough to enable 4 shopping bags to ﬁt

inside, while being small enough to ﬁt on a single ﬁle bicycle lane. It will drive around delivering groceries

from nearby supermarkets to customers starting in semi-rural areas of the Netherlands. In length and height,

it will be similar to standard bicycles but having a larger width to enable enough groceries to ﬁt inside. The

front is designed to look cartoonish and friendly with antennae’s for lidar cameras. The side will have sliding

side doors with a touchpad in the middle to allow for customer access to the groceries. The WupsE’s will be

made to allow for easy retroﬁtting of the outside to show grocery shop aﬃliation. As well as the ’skin’ being

made from soft materials (artiﬁcial hairs/feathers) to soften any collision. They are especially designed to

look cute and friendly and operate mostly next to cyclists on bicycle lanes.

1.2 What is wrong with a traditional startup for WupsE?

Startups are already experiments in themselves. An innovator leads a project with many hurdles to overcome

yet limited to the input of the founder(s). Bound by time management, ﬁnances as well as personal char-

acteristics and talent. Many of the hurdles faced by innovators are of similar nature that do not necessarily

involve working on the product. These include, but are not limited to; fundraising, marketing, creating slide

decks, and contractual paperwork. For most of these time-consuming tasks, helpful solutions exist out there.

Both paid and unpaid. However... it involves the innovator being aware of the opportunities that are there

and to reach out to them. This is an information and potential limit. Typically constrained by the number

of people involved in the project.

With the proposed decentralized (DAO) startup project, this is process is partially reversed. When out-

siders are made aware of the project by any way or form, they can actively reach out and contribute to the

project from the get-go, according to the rules laid out in the DAO smart contracts. This in turn reinforces

the project, as more contributors would also presumably lead to more awareness. While there is still a limit

on awareness, the reaching out is not done by contributors but in part by the progress of the project towards

its goal.

An interesting result from this would see the organizational structure itself as being on the receiving end

of a network eﬀect instead of the product that is being created. The product might be constrained to a small

niche market, in this case, a delivery robot in the Netherlands. Yet the organizational structure is not limited

in this way and contributors to the success of startup could grow exponentially, with each adding more value

https://elizabethyin.com/2021/09/19/the-rise-of-the-decentralized-startup/

In Development Caesar de Keijzer

according to their own talents.

This initial eﬀort constraint is another reason why an Open Startup is preferred. Most technological and

hardware hurdles relating to small sized, self-driving delivery robots have been solved to a great extent, at

least in the United States as well as China

. Yet their main impediment to deployment in the Netherlands

are regulators. With an Open Startup, regulators are a party to the table and have the voting power (outlined

in smart contracts) to steer deployment in way that is safe, responsible, and conscious. They also have full

insights into the open-source software development process from the start and thus on a rolling basis can

assess if safety is adequately prioritized.

The same holds true for all other external partners that are providing services such as external map and

software suppliers. They can readily view where and how to contribute inside the organizational structure.

The risks associated with contribution is also diﬀerent for these partners compared to a traditional startup.

Many times, a partnership with a startup rests on the delivery of future promises. With the terms of the smart

contracts being publicly viewable, they can actively contribute towards mitigating that risk. The promises

can be tracked and the suppliers and developers held accountable. With the risk being more decentralized as

well. Instead of waiting on the sideline for a ﬁnished product, external suppliers can contribute to the project

which shoulders some of the risks but also brings corresponding rewards and governance inﬂuence.

Another problem plaguing traditional startups is the curse of the founder’s head. With the entire company

plan being in the head of one single person. Never being stress tested or critically evaluated to a deeper level.

Undiscovered ﬂaws abound. One can easily see the problems arising from this. With distributive development

this is avoided as the execution and ‘brain’ of the company is laid out in smart contracts and open for everyone

to observe and contribute to. There is far less dependence on a single person. Though theoretically (since

this is still an experimental setup), as in any dependency graph, weak links will persist. Yet these weak links

are easier to replace and can be snuﬀed out earlier.

1.3 Who will be the parties involved in WupsE?

• Individual external providers

Outsiders, say a remote designer, can quickly decide to invest their time and eﬀort to a task outlined by

the members of the DAO and get rewarded accordingly. If this designer decides to abort the task midway

through, the smart contract executes the publicly viewable code and only for example pays half of the

promised reward. A new designer can view the outstanding reward and decide to continue upon the

previously done work to complete the contract. Due to the proliferation of remote work opportunities

and remote service providers, talented, international individuals can be more easily reached and tasked.

• External investors

Not every participant can/wants to contribute with their time towards this project. Like individual

investors and akin to crowdfunding, individuals can participate in this project with only their cash. Dif-

ferent in crowdfunding since ‘the crowd’ can buy both the product as well as a piece of the organizational

structure (not a company). Diﬀerent to (angel) investors in the sense that even minor contributions of

capital results in a contribution that supplies some voting power.

• The Creators

There will be a group of original creators/core members guiding the goal and organization forward

within a more full-time dedication. While steering the creation process to a bigger extent, their reward

is, akin to the other parties, outlined by the DAO and rewarded accordingly. Their rewarded voting

power and monetary reward is also proportional to their input work, and not, as is common in more

traditional startups, divvied up at the origin of the startup. This also relates to the hardware side of

WupsE, as this progress will be harder to reward by the DAO task management system, they will have

an outsize eﬀect on the progress.

• Dutch Government Regulators

The Dutch government regulations need to be updated. This happens also in occurrence with open-

source techniques where regulation can be made a dynamic process with issues created and solved by all

interested parties and where consensus needs to be reached. They can be either supplied with a share

https://www.economist.com/science-and-technology/sidewalk-robots-are-busy-delivering-groceries-while-autonomous-vehicles-wait-for-the-green-light/

21807601

In Development Caesar de Keijzer

of voting powers or can actively contribute and be rewarded accordingly, depending on the outline of

the DAO.

• Supermarkets (Jumbo, Plus)

Theoretically, supermarkets (both local and country wide) are most to gain from the development of

WupsE because it allows them to distribute their wares cheaper and easier because less employee time

is lost to driving around. It also enables them to provide a delivery service in (remote) areas where

this was previously diﬃcult to their cost-time trade-oﬀs of running a delivery service. They would be

the ideal customers of the WupsE product, yet can actively contribute to the development through the

modus operandi of the Open Startup. Instead of sitting on the sidelines, waiting for a ﬁnished product.

• Rapid delivery providers (Gorillaz, Flink, PostNL)

Rapid delivery providers currently only operate in major cities like Amsterdam and Rotterdam since

it isn’t feasible to expand their business to smaller towns and areas. The reason being A) not enough

available cheap drivers, often consisting of students and B) not enough demand from a dense, congregated

area. By upping their time scale (aka: rapid delivery in 40 minutes) and using WupsE to deliver, both

problems can be solved. Their current business model inside cities would not be aﬀected. Mostly

because deploying WupsE there would introduce various negative impacts, as further outlined in the

WupsE description down below.

• TNO

Maps and pre-existing software created by TNO allows for a quicker time to deployment and testing.

They have already been actively working and researching (fully ﬂedged) self- driving vehicles and would

allow this project to shorten deployment time while also integrating active research done on safe driving

protocols. Having an Open Organization allows them to bring valuable contributions to the project

while not having to deal with the bottleneck of detailed communication with the project creators.

• Operating Communities

The communities in which the robots are deployed will need to be ensured of their safety. Independent

contractors can do this more easily with most of the source code being easily viewable. The same goes

for local citizens who want to check upon, or actively participate in the safety of the system or bring it

into their neighborhood. By straight away contributing to the goal of the OS, they can speed up the

rollout in their area. As well as follow the progress in this rollout.

2 WupsE details

2.1 Product motivation

As online ordering of food and groceries becomes ever more ubiquitous in our Dutch society, new problems

arrive. Few of these issues are associated with the delivery side of the business. We aim to alleviate these

troubles by introducing WupsE: a self-driving delivery car(t) with a few caveats that make it exceptionally

suitable for the Dutch market.

Since delivery in the Netherlands is mainly done by bike, the opportunity also exists to have our WupsE

delivery robots drive exclusively on bike paths. The bike network path network is expansive, well taken care

of, and standardized. Road users are already very visibly aware of cyclists and paths are separated from the

main road, reducing the potential for car-WupsE accidents.

While bikers-cyclist related accidents could be potentially higher, they will hypothetically lead to less deadly

collisions because the delivery robots are smaller, nimbler, and slower than a full-ﬂedged car.

Furthermore, their potential use is also highest in more remote areas of the Netherlands where there are

adequate bike paths but limited bikers and thus limited possibility for a delivery service to operate. Imagine

a local village supermarket using our WupsE’s to deliver groceries to the neighborhood elderly without having

to sacriﬁce employees in the process.

Their use will also be limited to quitter times of the day such as midday or at night to limit hinderance

to traﬃc and cyclists. Algorithms and data science insights will help in ﬁnding optimal timings to reduce

collisions. Further product speciﬁcations will help in harm done in the chance of any collision occurring and

are explained below.

In Development Caesar de Keijzer

In Development By: Caesar

Figure 1: Bakfiets as reference point for size and width

Product description:

 WupsE with 6 wheels (3 on either side)

 Width: 70cm x length 100cm, height 75cm

 Body and chassis are separable allowing quicker modifications/replacing if damaged

Body:

 4 compartments (1 compartment is size of 1 shopping bag)

 Compartments are standardized and exist in 3 forms: neutral, cold, and warm

 Outside of the WupsE is layered by soft material (fake fur) to reduce collision

damage

 Sideways sliding doors for access to delivered items

 Easily colorable to show grocery shop affiliation (AH, Jumbo, Gorillaz, Flink)

Chassis:

 Electric battery in chassis

 Front Ultra sensor: in the form of a mouth

 Two headlights, including radar and cameras: in the form of cartoon eyes

 Wheels: covered from the sides, made look like soft feet

 Programmable horn

 Two Lidar on top: in the form of antennae

 Two side cameras & radar

Product specifications:

 Electric chassis, battery charged

 Weight excluding groceries: x Including groceries: x

 Max carry:

 Speed: 12km/h  20 km/h

Figure 2: Bakﬁets as reference point for size and width

2.2 Product description

• WupsE with 6 wheels (3 on either side)

• Width: 70cm x length 100cm, height 75cm

• Body and chassis are separable allowing quicker modiﬁcations/replacing if damaged

Body:

• 4 compartments (1 compartment is size of 1 shopping bag)

• Compartments are standardized and exist in 3 forms: neutral, cold, and warm

• Outside of the WupsE is layered by soft material (fake fur) to reduce collision damage

• Sideways sliding doors for access to delivered items

• Easily colorable to show grocery shop aﬃliation (AH, Jumbo, Gorillaz, Flink)

Chassis:

• Electric battery in chassis

• Front Ultra sensor: in the form of a mouth

• Two headlights, including radar and cameras: in the form of cartoon eyes

• Wheels: covered from the sides, made look like soft feet

• Programmable horn

• Two Lidar on top: in the form of antennae

• Two side cameras & radar

In Development Caesar de Keijzer

2.3 Product speciﬁcations

• Electric chassis, battery charged

• Weight

– excluding groceries: x

– including groceries: x

• Max carry:

• Speed: 12km/h – 20 km/h

2.4 Product justiﬁcation

Why here?

Cycle infrastructure in the Netherlands is well maintained, comprehensive and standardized. This allows

our product (WupsE) to operate safely away from busy car lanes and thus requiring a less advanced sensor

network since diﬀerent road operations are required. The standardization of bike paths (minimum of 1.25

meters) further helps our product to be able operate wide, but with less chance for problem possibilities.

Competitors that operate solely on roads will require much more stringent and diﬀerent safety standards

than WupsE. While similar companies that operate on sidewalks, like those in the US, will have a wider

variety of environments to navigate, speed limitations (6km/h) as well as lower awareness from pedestrians

to consider.

Figure 3: Canta car with cyclist

The “Handboek Wegontwerp”, advises that roads outside build up areas have a cycle lane with a minimum

width of 1,25 meter and a max of 2.50 meter. Canta’s are are similar (human operated) vehicles in existence

currently that operate in the same space (cycle lanes). Their width being 1.10 meters, considerably more

than the proposed width for WupsE, cyclists would be already familiar with other vehicles operating on these

cycle lanes.

Professional services company KPMG’s 2019 Autonomous Vehicles Readiness Index has also placed the

Netherlands top of its table as the most prepared country to welcome self-driving vehicles

Why now?

The technology to create this concept is more abundant than ever, the infrastructure is already there. Lidar

technology has signiﬁcantly dropped in price as well as being further miniaturized. The diﬃculty on the

delivery job market, as well as new entrants to the fast delivery service business concept (Gorillaz, Flink,

Zapp) creates a lot of competition for drivers. It leaves space open for other opportunities to help them solve

this hiring problem. It also allows their respective services to expand to more rural areas where recruiting

https://home.kpmg/xx/en/home/insights/2019/02/2019-autonomous-vehicles-readiness-index.html

In Development Caesar de Keijzer

young (often student) workers is considerably more diﬃcult. Albert Heijn (AH) is also currently working

on their own concept delivery vehicle showing that there is corporate interest. Present our solution to an

alternative could attract funding from their competitors instead of having these companies develop vehicles

inhouse.

Experience from the product team at the VU university in designing and programming for the NXP cup also

signiﬁcantly helps development. The motivation, knowledge, and experience to start is currently present.

Product team

• : VU bachelor students, experience through NXP cup

• : Master VU students (contact through )

• x: external partners through partnerships

• x: Onboard a hardware Engineering student

• Advice : TNO contact

• Development by the Vrije Universiteit and partners (help from bicycle car creators from fast bicycle

challenge)