Hiring is one of the ways Dashdoc becomes itself. We look for a mutual fit: people who share our values and way of working, and who will also leave their own mark on the team.

Dashdoc is the transportation management product used by thousands of carriers and shippers in Europe. Our engineering team is 40+ people. This post is simply how we hire today: what you’ll go through, in order, and what we care about.

Heads-up: We tweak this process over time. What you read here is our current version, not carved in stone.

Order and pace: The sequence below is the usual one, but it can shift a bit depending on calendars (yours and ours). We don’t have a single fixed “standard duration”: it depends on how fast we can book slots and how deep we need to go. We aim for steady progress once we’ve started: concrete dates, keeping back-and-forth over email to a minimum, and a clear “where we are” when you ask.

Selection process: So far, every CV is read by a human, no automated filtering. We can’t commit to giving personal feedback to every applicant, but every application is genuinely read. When we don’t move forward with someone, it’s usually less a matter of skill level than of fit for the specific role we’re hiring on.

The rounds

Every step is a two-way conversation: we try to be clear about what that slot is for, you can ask us anything, and nothing here is meant to trip you up. We leave time in each session for your questions on the role, the stack, how we work, or what comes next.

Why these rounds

We want our interviews to reflect the actual work, not reward people for being good at interviews. Day to day, our engineers read unfamiliar code, debug real systems, shrink big problems into shippable slices, and talk about trade-offs with people who aren’t engineers. The mix below is what we’ve found maps best to that, including the parts that are tiring for everyone, because hiring without enough depth tends to hurt both sides later.

1. Screening call, ~30 min, remote 💬

We use the same baseline questions for everyone so it stays fair, and so we don’t forget the basics.

We want to know your path, what you’re looking for, and what drives you. You can ask us anything, we’ll be straight about what’s great here and what’s hard.

This is usually conducted by an engineering manager, and it’s a good opportunity to ask us anything you want to know about the role, the company, the team, the stack, etc. You’ll be asked about your salary expectations, your availability, your notice period, etc.

What helps on your side: you don’t need to “study.” A rough idea of what you’ve done recently, what you want next, and why Dashdoc (even if that reason is still fuzzy) would work for you. If you’re unsure about seniority, team, or scope, don’t be afraid to say it!

2. Technical test, ~45 min to 1 h, remote 🐛

No whiteboard. No LeetCode.

You get a full-stack debugging task on a small, messy legacy codebase. The goal is for it to be closer to “joining a team” than to a textbook exercise (our codebase is tidier than the exercise, for what it’s worth 😅).

We care how you find your way in unfamiliar code: how you read it, what you ask, what you’d change and why. We’re not testing whether you’ve memorized Django or React. We are used to interviewing people with no experience on our stack; we’ll help with details if you need it. We’re interested in how a typical SaaS (frontend + API + how they talk) fits together.

The bug itself isn’t huge; what we care about is how you navigate unknown code calmly and methodically.

Format: it’s a live session with engineers from the team. You share your screen, explore the repo, and talk us through what you’re seeing. We’re not grading your typing speed; we’re watching how you structure the search (where you look first, what you verify, how you narrow it down). If you’re stuck, say so! We’d rather see how you unblock with help than watch anyone pretend.

What helps: a quiet slot and a good internet connection. Let’s be honest: the bug itself is usually not the hardest part, yet this is the most selective step, because it shows how clearly someone can build a mental model of unfamiliar code and follow the execution path under time pressure. My advice: don’t rush, have no assumptions about the code, just follow the code and how the frontend and backend interact.

3. Product & tech shaping, ~1.5 h, remote or on-site 🎯

This part is a bit specific to us, and we like it.

We imagine you’re shipping an MVP for a product idea. Together we shape scope: what is the problem we’re really trying to solve, who is it for, what ships first, what waits, how you’d structure it, what you’d bet on technically.

There’s no model answer. We want to see how you think with us: product sense, trade-offs, and how you explain choices. At Dashdoc, engineers own features end to end (problem → ship); this session is a compressed version of that kind of discussion.

Format: we bring a short written brief; the rest is discussion. Whiteboard, notes, bullet lists, whatever helps you think. It’s normal to challenge the premise, to ask “who is this for?”, or to change your mind once we add a constraint. We’re not scoring a slide deck; we’re watching how you collaborate under uncertainty.

4. The “Who” interview, ~45 min to 1 h, remote or on-site 📖

Loosely based on the Who approach: we walk through your story. What you built, what you’re proud of, what you’d do differently, how you grew.

We’re listening for how you work: ownership, honesty about mistakes, curiosity.

What to expect: we’ll spend time on a few chapters of your career, not every bullet on your CV. Come with 2–3 examples you’re happy to go deep on (a messy project, a conflict you handled, a decision you’d revise). Specific beats abstract every time.

5. Reference calls 🤝

We’ll ask for a few people you’ve worked with (peers, managers, etc.) and have short chats with them. It rounds out what interviews can’t always show: strengths, how you collaborate, and where you’re still growing.

We usually ask for references when we’re seriously considering an offer, not as a generic paperwork step at the start. We’ll tell you what we’re trying to learn so you can pick people who’ve actually seen you work.

6. Meet a founder, ~30 min, remote ☕

Informal chat with our CEO or CTO; where the company is headed on our side, what pulls you in on yours. A last mutual check-in before we hopefully work together.

Why it’s there: at our size, founders are still close to strategy and culture. This isn’t a veto round on trivia; it’s a chance for both sides to sanity-check “does this still feel right?”

Things we want you to know 💛

You can stop anytime, so can we.

If Dashdoc isn’t for you, say so; we’ll take it well. If we don’t continue, we’ll tell you as soon as we can.

We try not to drag things out.

Long ghosting helps nobody. We want enough time to decide properly, without losing momentum.

We hire the way we’d want to be hired.

Interviewers know the brief: be explicit about what each round is for, give you room to think out loud, and answer your questions honestly. We’re not playing roles or setting ambushes, we’re checking whether working together would make sense on both sides.

That lines up with how we talk about our values day to day. Care means feedback you can use and a no that comes with clarity, not silence. Ambition and Passion show up in serious, engaged conversations, not in pressure tricks. Speed is about respecting your time: keeping the process moving and not leaving you guessing for weeks.

You don’t need a logistics background. Some of us knew freight before joining; most didn’t. You just need to be curious about the domain!

We’re still improving this

Like any product, our hiring process gets feedback and iterations. We ask candidates and interviewers what felt fair, clear, and respectful.

If something was confusing or unnecessarily heavy, we want to know! It helps us fix the process.

Been through it? We’d love your honest take. Thinking of applying? Hope this helps you know what to expect.

If helping reshape how transport runs sounds like your kind of problem, we’d love to hear from you.

How we hire engineers at Dashdoc was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we started Dashdoc more than eight years ago, our goal was simple: make transport management easier and more transparent. What began as a small product has grown into a platform used by thousands of carriers and shippers across Europe (and soon the US!). Along the way, our engineering team grew to more than 30 developers, and with that growth came lessons, false starts, and a clearer sense of how we want to work.

Our values: Care, Ambition, Passion, and Speed, shape both our product and our engineering culture. They guide how we ship, how we collaborate, and how we grow. Here’s a look at what that means in practice.

Shipping with purpose, not just speed 🚀

In the early days, speed often meant rushing features out the door. We moved quickly, but we sometimes found ourselves rewriting the same code weeks later. Those moments taught us an important lesson: speed only matters if it’s sustainable.

Now, we focus on shipping with purpose. That means releasing in small, frequent increments instead of large batches, keeping risk low and feedback loops short. It means choosing pragmatic solutions that solve today’s problems without creating tomorrow’s bottlenecks. It also means taking technical debt seriously; not as a distraction, but as essential maintenance for long-term velocity.

Automation is what makes this sustainable. Strong test coverage, type checking, and continuous integration give us confidence. The safety net allows us to move quickly without second-guessing every change.

Engineers who think product-first 🧑‍💻

At Dashdoc, engineers don’t just write code; they own features end to end. We believe the best outcomes happen when developers are close to the “why,” not just the “how.”

That translates into full-stack ownership. While some of us lean backend or frontend, everyone is encouraged to work across layers — from infrastructure to UI — if that’s what it takes to deliver. Just as importantly, we invest time in understanding the business domain. Transport logistics is complex, and the best technical choices often come from understanding a dispatcher’s day-to-day reality as well as the intricacies of a codebase.

Developer experience is team speed ⚡

We think of developer experience (DX) as the engine behind both speed and quality. A clunky workflow slows everything down; a smooth one makes shipping fast, safe, and enjoyable.

This shows up in our codebase, which we want to feel both efficient and pleasant to work in. Clarity matters more than cleverness. Conventions are well defined so no one wastes time guessing patterns.

That’s why we invest in DX as a first-class priority:

• Clarity over cleverness: code should be easy to read and reason about, even for junior developers. That’s what makes it easy to improve and easy to debug.
• Clear conventions: well-defined patterns and practices keep focus on solving problems, not guessing how to write code.
• Automation everywhere: repetitive tasks belong to scripts and pipelines, not humans.

A good developer experience pays back in more than happiness. It means fewer bugs, faster delivery, and a team that has the energy to keep improving.

Care in collaboration 🤝

One of our core values is “Care,” and it shows in how we collaborate. We review code with rigor and empathy. We share knowledge openly, so no expertise stays siloed. We balance ambition with pragmatism, aiming for excellence without burning people out.

Pair programming has become central to this. It accelerates learning, improves quality, and keeps remote teammates connected. Some of our best solutions came out of two people sharing a screen, exploring a problem together, and finding a better answer than either would have alone.

Growing with ambition 🚀

We’re still small compared to the giants of our industry, but our ambition is large: to change how transport is managed across Europe and beyond. To do that, we need an engineering team that grows in skill, scope, and impact.

Growth at Dashdoc isn’t limited to becoming a manager. Some of our strongest contributors are individual engineers who have taken ownership of complex domains, driven architectural changes, or mentored teammates. We want everyone to see their personal development aligned with the company’s growth — whether that path leads to leadership or deep technical expertise.

Takeaway ✨

Our engineering culture is about moving fast with purpose, building with a product mindset, and investing in developer experience as a multiplier of both speed and happiness. We collaborate with care, and we grow with ambition.

The journey hasn’t always been straightforward, but each lesson has made our team stronger. As we continue to expand, we’re excited about what comes next — and about shaping the future of transport logistics together.

How We Build Software at Dashdoc was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

This story is co-authored with Jules Ricou, who implemented extended diagnostics into the tool.

Introduction

Like any company providing on-line services, Dashdoc strives to deliver performance to its beloved customers. If performance drops, everybody suffers, starting from our customers up to our customer success team, our CEO, and of course, us, techies. We are really a bunch of empathic Care Bears at Dashdoc ☺️.

Jokes aside, technically, we have several aspects we look into for performance : pure DB optimisation (Use the Index Luke), React UI performance, Django performance, and overall integration sanity (allow the UI to do bulk operations instead of tens or hundreds of similar calls for example).

We already talked about avoiding one aspect of N+1 in Django.

Filter Django QuerySets In Memory

We described in that previous article two variations of this issue in our code:

• The typical instance.related.attribute version: if instance.related was not prefetched it would issue a new DB call.
• The less obvious instance.related_set.filter(column=value) version.

It gave an overview of how we tackled the second point. So in this article, we will explain how we tackled the first issue which is : not doing the correct complete prefetch.

The problem

During 2022 we became obsessed with performance issues. We were aware that our Django code did undesired implicit requests in different places, and although we kept adding unit tests with assertNumQueries we knew we were not always creating the situation where those tools would catch extra queries.

Indeed, to catch N+1s in tests reliably, the setup is often tedious. Of course, we will create numbers of first or second level entities — which are those we want to test — but the devil is in the details : we might forget to create enough remotely connected entities to catch redundant SQL queries, those entities that you will access in your business logic and completely forget they need to be prefetched.

The intuition

Eventually, we figured out a way to gain some insight on those N+1. Specifically the case where a instance.relation wasn’t loaded. In Django’s ORM, there is one point where we can sit and look at the accesses to the data: FieldCacheMixin.get_cached_value.

🐒 Careful, monkey-patching ahead! Monkey-patching is an often frowned-upon technique to dynamically reconfigure code. Among the reasons that make reviewers frown are that it can introduce hard-to-discover behaviours and that it often patches internal APIs. However, sometimes the benefits outweigh the drawbacks so much!

We monkey-patched FieldCacheMixin.get_cached_value with our own version which logged cache misses and a script was written to collect those logs and identify which QuerySet was missing a prefetch_related or a select_related.

This is the original monkey-patch.

def install_missed_prefetched_detector():
    def get_cached_value(self, instance, default=NOT_PROVIDED):
        cache_name = self.get_cache_name()
        try:
            return instance._state.fields_cache[cache_name]
        except KeyError:
            if default is NOT_PROVIDED:
                # _REPORTER just does whatever you want to do: 
                # system log, sentry, raise, spam slack, keep quiet.
                _REPORTER(cache_name, instance)
                raise
        return default

    FieldCacheMixin.get_cached_value = get_cached_value

We continued this tedious hand-crafted way for a few months, letting the logger log, and running manually a script to analyze our logs every now and then to find the next code paths to target.

The solution

Finally, during a cool-down, we used the same monkey-patching approach and built a decorator for our unit tests : @break_on_missed_prefetches.

How we organize our work — Shape Up

Its role was to make the test fail as soon as FieldCacheMixin.get_cached_value missed its cache, indicating an N+1.

Concurrently, we had already a helper testing class to centralize all the API calls we used in our tests, like:

class TestClientMixin:
   def api_create_transport(self, *args, **kwargs):
       self.client.post(
           # ...
       )
       
   def api_assign_trucker(self, *args, **kwargs):
        self.client.patch(
            # ...
	)

And all our tests use these methods. All we needed was to decorate those methods to start guarding our code against missed prefetches!

class TestClientMixin:
   @break_on_missed_prefetches
   def api_create_transport(self, *args, **kwargs):
       self.client.post(
           # ...
       )
   @break_on_missed_prefetches
   def api_assign_trucker(self, *args, **kwargs):
      self.client.patch(
           # ...
      )

Bingo! As soon as a missed prefetch happened, we got an exception and the test failed. No need to set up complex data situations and count the number of queries to detect the issue! The expected related object is not there? Then it is an error.

We later enforced decorating these methods with a Semgrep rule. By using it every day, we iterated the tool quite extensively.

• Firstly, we improved this tool to also catch deferred fields being fetched: .only(...)and .defer(...) can be used to avoid fetching all fields of a model, and in our case accessing those fields is a sign of a bug.
• Secondly, we added the call stack of the location where the query was executed, to that end, we monkey-patched QuerySet._fetch_all to assign it to the model that was fetched. This solution being only useful for developers (and being quite expensive) is disabled by default. It is often useful because if you miss a prefetch, you most likely want to add select_related / prefetched_related to the query.
• Finally, with a deep hierarchy of prefetch/select_related it can be hard to find the related object with only the message “implicit query accessing <field> on ModelClass”, to help us we store the parent of children entities from withinFieldCacheMixin.get_cached_value. With this information we can go as far as constructing a likely answer to fix the query: “Hint: add ‘.select_related(grand_parent__parent__field’)” to the query.

Conclusion

Nowadays, the decorator is called @break_on_implict_queries and reports a lot more information to make it even easier for us to pinpoint incomplete querysets. We go all the way into giving the faulty queryset and where it is defined, together with where the failing N+1 call happened. We also cross the boundary of Celery tasks to be able to debug them too.

Besides the decorator used in tests, we can turn on the mechanism in our developing environment to catch the mistakes early.

This tool has proved to be a very valuable addition to our performance tuning tool kit. Its integration in our unit testing makes sure we don’t let missed prefetches go live. Although it doesn’t completely avoid false positives (for example situations where doing the correct prefetch explicitly or letting Django do the query lazily implicitly makes no performance difference) we use it as a proactive tool to avoid heavy production performance incidents.

More recently, this tool caught an issue while migrating to Django 5. An extra query appeared in complex situations. The investigation is still ongoing to pin-point what is wrong though.

But we were not done yet, performance is an ever lasting battle and the following year, 2023, was crucial for us in that regard.

Hunting N+1 errors in our Django code: the implicit queries case. was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

Django’s ORM is great to work with business entities. It also provides tools to do efficient queries with QuerySet.select_related (for to-one relations) and QuerySet.prefetch_related (for to-many relations).

But even so, it is easy to write code that hits the database too many times. This happened to us on our spreadsheet export system. This system was vital for our customers as it was, back then, the only way for them to move data from Dashdoc to their invoicing software, as we didn’t yet have the third party integrations we have today.

The system would be used to export thousands of transports at once, and we would quickly run into timeouts. We did have a thorough eager loading at the beginning of the export procedure.

After some investigation we found two variations of the N+1 problem:

• The typical instance.related.attribute version: if instance.related was not prefetched it would issue a new DB call.
• The less obvious instance.related_set.filter(column=value) version.

Both required fixing. We tackled both and developed some tools to guard us against them. In this blog, we will talk about the second problem.

The problem

The faulty code was in extractors. These extractors are functions that receive a Transport and extract data from it or from its related instances. The following pattern appeared very often :

some_data = transport.related_set.filter(attribute__operator=value)

This came from the misconception that a .filter() can work on the already fetched data. And it could indeed be very handy, once you are used to Django’s ORM filtering syntax, it is natural to want to use it everywhere.

Except this hits the DB, not the prefetched data. Now repeat this for tens of related instances for thousands of transports and you get the idea.

The (odd but satisfying) solution

When a QuerySet is evaluated, it holds the data in a cache. And if there happens to be select_related and prefetch_related in the QuerySet’s clause, then the instances in the cache will themselves have caches for related to-ones and to-manies.

Since we already had a correct eager loading at the beginning of our export procedure, all the data was already in memory, but was being ignored because of the subsequent .filter() calls.

What we came up with is a module called in_memory_filtering. It very simply implements Django’s ORM filtering syntax to work over the QuerySet. So the previous example becomes :

from in_memory_filtering import filter_set

some_data = filter_set(transport.related_set.all(), attribute__operator=value)

Sounds dumb? It is! The implementation is as straightforward as it can be. No caching strategies, no indexes. We just iterate through the QuerySet and convert the filter expression(s) into lookups on the instances of the QuerySet as many times as requested.

Indeed, once the QuerySet is fetched, one can iterate over it without hitting the DB again. And the magic is that it works in related sets too : instance.related_set.all() will return the cached data!

This very simple implementation serves as the base to express the equivalents for :

• QuerySet.first()
• QuerySet.values_list()
• QuerySet.values()
• QuerySet.get()

The only catch there is, is that by design, it doesn’t prevent accidental DB accesses: we prefer some accidental extra DB hits than a user facing exception or missing data.

It looks silly and over-engineered

Yes, this is nothing that can’t be done in other ways. And even more efficiently too! Actually, compared to a list comprehension, there is more machinery involved to evaluate the filtering expressions, so this adds overhead.

But it is enough for us to have decently fast and reliable exports. What this module actually provides is not a technical breakthrough. It instead tries to sit somewhere between raw efficiency and programmer friendliness.

It aims to be easy to adopt by a Django developer. The expressions used in faulty .filter() queries can be easily converted since the syntax is the same (we added the negation of the operator : __not__eq). It supports JSONField. Also, when the expression uses unknown attributes that do not exist on the filter instances, we provide error messages similar to Django’s Cannot resolve keyword ....

Is is also a good place to put sanity checks on the querysets being filtered.

Conclusion

The in_memory_filtering module has been in use for more than two years now and was the first bit of code we rolled out to fight against performance bottlenecks. But it only works if the eager loading is properly done. So, since then, we have added tools to guard us against missed prefetches and it is now one tool in a growing toolkit to deliver more performance to Dashdoc users.

Filter Django QuerySets In Memory was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

OpenAPI is the standard nowadays to specify your API. Among the benefit of using it, you can generate nice documentation out of your specification. In this article, we will go from documentation writing to having a web page for your API documentation.

It is important to note that there are solutions to auto-generate your OpenAPI specification from your code and we actually started with that. For example, you can use drf-yasg for Django Rest Framework. However, this kind of library has its own limitations when it tries to automatically discover new endpoint specifications, especially if the implementation is a bit complex. Because the documentation was not reflecting the reality anymore, we decided to switch to the solution presented here.

Describe your API using YAML

The specification can be written either with YAML or JSON. We suggest using YAML because you can split it across several files making it easier to read and maintain.

Below is a simplified version of our API documentation entry file.

openapi: 3.0.1
info:
  version: "4.0"
  title: Dashdoc public API
servers:
  - url: <https://api.dashdoc.eu/api/v4>

paths:
  /addresses/:
    $ref: "./paths/addresses/addresses.yaml"
  /addresses/{id}/:
    $ref: "./paths/addresses/addresses-id.yaml"

The main interest of the YAML usage versus JSON is the $ref keyword that allows us to split the specification into smaller files and avoid text duplication.

We split our files into 2 main directories, one where we describe the endpoints (the ./paths/ visible above) and another to describe the objects manipulated by those endpoints. It helps us keep things tidy.

Convert YAML to JSON definition

Having a YAML definition is nice but in most cases, we need the JSON version.

This can be easily done with the help of OpenAPI Generator. This tool is often used to generate an API client (SDK) for the provided API definition. But it can also be used to convert the YAML definition into a JSON file.

OpenAPI Generator is written in Java. There are several ways to install it (see documentation). We chose the Docker image to avoid handling the java dependency and keep our local environment clean.

docker run \\
    --rm \\
    -v $BASEDIR:/docs \\
    openapitools/openapi-generator-cli generate \\
        -i /docs/v4.yaml \\
        -g openapi \\
        -o /docs/tmp/v4

Parameters explanation for docker:

• --rm: Automatically remove the container when it exits
• -v: Bind mount a volume. Associate a local directory to a directory inside the container.

Parameters explanation for openapi-generator-cli generate:

• -i: Input data, here, the main YAML file.
• -g: Generator name, always openapi for the documentation.
• -o: Output directory. The JSON definition will be saved here. It should be something within the mounted volume if you want to retrieve it on your local directory.

Finally, the $BASEDIR matches the local path in your environment where you store your documentation.

Serve your API documentation using redoc

As said in the introduction, the JSON definition is often used by other tools. One of them is [redoc](<https://github.com/Redocly/redoc>), which generates interactive API documentation from OpenAPI definitions.

As you can read in their documentation, you just need to create an HTML page and use a <redoc> tag with the URL to your JSON definition file in it!

<!DOCTYPE html>
<html>
  <head>
    <title>Redoc</title>
    <!-- needed for adaptive design -->
    <meta charset="utf-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link href="<https://fonts.googleapis.com/css?family=Montserrat:300,400,700|Roboto:300,400,700>" rel="stylesheet">

    <!--
    Redoc doesn't change outer page styles
    -->
    <style>
      body {
        margin: 0;
        padding: 0;
      }
    </style>
  </head>
  <body>
    <redoc spec-url='<http://petstore.swagger.io/v2/swagger.json>'></redoc>
    <script src="<https://cdn.jsdelivr.net/npm/redoc@latest/bundles/redoc.standalone.js>"> </script>
  </body>
</html>

Check out our live documentation to have an idea of redoc: https://www.dashdoc.eu/api/v4/docs/

Tailored API documentation with OpenAPI was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

In France, oil is getting more and more expensive and we realised that our prospects and customers current biggest pain was to increase their invoices to their customers in order to keep their margin.

Our objective was to help them quickly with a tool and make them aware of Dashdoc.

Only 3 days lasted between the slack channel creation about the topic and the website launching.

After the product team spend the first day digging into the need and building strong documentation that sums up what we found about the topic, we started designing an MVP.

Design and implement the MVP

I started by prototyping the website on Figma (not pixel-perfect at all) just to illustrate what we were talking about. Two ideas emerged from this first step :

• On the left, a complex online tool
• On the right, a simple download page

We wanted to ship quickly and stay simple so we choose to implement the second option. To implement this I used WebFlow because I heard that I could create a website in minutes and that’s real: it’s powerful.

Everyone was working together in symbiosis:

• our finance manager Hélène was creating the Excel tool,
• the marketing team was thinking about the content (title, CTA text, excel file) and the communication to promote the website (Blog article, Newsletter, LinkedIn post, Webinar)
• and I was creating the first iteration of the website on WebFlow.

Time to ship!

On the second day, we already had a functional website.

A simple download page with a form linked to our CRM. On submitting the form, a workflow is triggered in our CRM that sends the Excel file by email.

On the final day, we connected the related domain indexation-gazole.fr that we bought for the occasion to the Webflow website within minutes and we launched communication on all our social media.

Conclusion

This small campaign resulted in 300 new leads in a month for 3 days of conception/development.

We will now work on SEO to start generating organic traffic by adding more useful content to become the reference website about the topic.

Three key factors have made this possible in such a short time:

• Use only low code tools to iterate as fast as we can
• Strong internal communication
• Keep the user’s pain in mind

At Dashdoc we move fast and adapt quickly to the needs of our customers, if you’re looking for challenges, come reach us.

How did tech and marketing work together to ship a website in 3 days? was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

The setup

2 years ago, we had 3 fresh new engineers in our tech team (5 in total), and at last, a real product manager who helped us square things up. We started planning sprints again, feeling good about the new process.

But things started feeling off. As a founder I was used to having a lot of freedom in how I planned my work, and I was used to owning the whole development flow, from design to implementation and deployment.

Now we were spending a lot of time in retrospective meetings, in planning sessions, splitting hairs trying to estimate points for user stories. It was a lot of work for our product manager to write these detailed specs and user stories for everyone, and it was not even pleasant for the tech team.

I felt that this way of working was mostly holding back the best people in the team and helping mostly the more junior people.

We were processing ticket after ticket and hoping that the end of the sprint would bring the whole epic together. What happened is that we ended up in integration hell and the parts developed in isolation did not fit together so well. It felt more like a mini-waterfall than an agile process.

There was no ownership in the tech team; every person was responsible for a small part of a feature, and then we tried to glue it all together.

With the team growing, things were only going to get worse if we continued on the same path. So I started looking around to see if there was another way of doing things, and I found Shape Up.

Shape Up

The tagline for the Shape Up book is “Stop Running in Circles and Ship Work that Matters”.

The basic idea is the following:

• New features are described in “pitches” where a pitch is a short document outlining the problem we are solving, why it matters, and what we intend to build to solve it. The specification of what we’re building is voluntarily light on details; it’s more precise than an idea but less than a full mockup.
• The development cycle is 8 weeks long, split into 2 parts: 6 weeks working on pitches, and 2 weeks of “cool-down” where the tech team can spend time working on technical improvements. The idea is that 6 weeks is long enough to tackle important work but short enough that you can feel the deadline. (Intercom also has a good article on why 6 weeks is a good cycle time)
• One or two devs work on a single pitch (“big batch”) or a few pitches (“small batch”) together during the cycle.
• A small team of core people writes the pitches (mainly the product manager in our case).
• Before the beginning of every cycle, we have a meeting called the “Betting table” where the co-founders and heads of all departments choose together which pitches will be selected for the upcoming cycle.

Starting out

Once a few of us in the team had read a few articles and the Shape Up book, we were convinced that we could try it out for real. We shared some resources with the whole team, took time to explain what we were going to try and why. We wrote enough pitches to have a first full cycle, and we held the first betting table.

The first thing we gained from holding the betting table meeting is that it aligned the whole company on what we were building in the product. No more trying to add a “small feature” at the last minute to sign a customer.

What went well

Things went pretty smoothly from the start, and everyone felt a lot more productive. The product team had a lot more time to spend on discovery, the engineers could concentrate on one subject at a time.

There is a lot more ownership in the tech team. The goal is to solve the user’s problem during the cycle, and the pitch can and should be challenged to make sure we reach this goal.

During the past 2 years, the product + engineering team grew to about 25 people split in 4 teams and the method scaled nicely.

Adapting the method to our needs

Unlike Basecamp, we don’t serve only small businesses on the same pricing, and we have a high-touch sales cycle. In many ways the Basecamp model is closer to B2C; they can choose to ignore some of their customers much more easily. Our customers range from independent truckers to enterprise companies with thousands of users, so we had to adapt the method to our needs.

• The main thing we didn’t keep from the book was the idea to only fix bugs during the cool-down. We have a product that is critical for our users and most of the time we can’t wait a few weeks to fix a bug. At first, we had the whole team dedicated every Tuesday and Thursday morning to bug fixing. We found that this was not great in terms of focus (one of the main goals of Shape Up) so we’re now experimenting with a “Delight team”. The Delight team’s goal is to fix bugs and implement small features that can be blocking the onboarding of new customers, and generally help unblock the ops team any way they can.
• At first we tried not to commit to a roadmap, then we added an “orientation meeting” in the middle of the cycle to give visibility in advance to the rest of the team, and finally as we pivoted our product to a full transport management platform we returned to a roadmap as the objectives for the next ~6 months are very clear.
• We create one Slack channel per pitch, where the engineering, product, and customer success can talk about ongoing work on the feature.
• We do not use hill charts to communicate progress. More generally, each team can choose to organize their work how they see fit. Some hold daily standups, some only have a weekly meeting, some use Notion to track their work, some use Linear…

Still figuring it out

After each cycle we hold a retrospective and change our workflow to better fit our needs. As the team grows, new challenges arise and we have to keep updating the way we work.

How we organize our work — Shape Up was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.

The aim here was to get the weight of the load of a transport from a ticket picture taken by a trucker.

These weight notes can have various different layouts, often several weights are present on the tickets, they are not all in the same orientation, we have handwriting, blurred pictures, shadows…

The general approach was to proceed step by step, splitting the problem into successive subtasks:

1. Straighten the document
2. Extract the text from the image
3. Find the requested weight parts in the text
4. Rebuild the weight

Straighten the document

Thanks to a tool we use on the mobile side, most of the pictures are reframed around the document we want. But it can lead to documents with a 90° angle.

We chose to straighten these images as an automatic preprocessing. The idea was to make the task easier for the following steps.

To do so, we built an image classification model. We used transfer learning, taking a MobileNet model pretrained on ImageNet, on top of which we added some layers to fit our problem of 4 orientations (0°, 90°, 180°, 270°) classification. We trained these new layers on 1000 training tickets coming from our database, that we annotated with a home-made annotation tool, based on OpenCV. At the end of the training, we chose the model that gave the best result an on another 1000 validation tickets. This was done using Keras.

import tensorflow as tf

idg = tf.keras.preprocessing.image.ImageDataGenerator() 
training_data_generator = idg.flow_from_dataframe(
    training_data, directory=output_path,
    x_col="filename", y_col="orientation",
    target_size=(224, 224),
)
validation_data_generator = idg.flow_from_dataframe(
    validation_data, directory=output_path,
    x_col="filename", y_col="orientation",
    target_size=(224, 224),
)

inputs = tf.keras.Input(shape=(224, 224, 3))
scale_layer = tf.keras.layers.Rescaling(scale=1 / 127.5, offset=-1)
x = scale_layer(inputs)
base_model = tf.keras.applications.MobileNet(
    weights="imagenet",
    input_shape=(224, 224, 3),
    include_top=False,
  )
base_model.trainable = False
x = base_model(x, training=False)
x = tf.keras.layers.GlobalAveragePooling2D()(x)
outputs = tf.keras.layers.Dense(4, activation='softmax')(x)
model = tf.keras.Model(inputs, outputs)

model.compile(
    optimizer=tf.keras.optimizers.Adam(),
    loss='categorical_crossentropy',
    metrics=['categorical_accuracy'],
)
checkpoint = tf.keras.callbacks.ModelCheckpoint(
        save_dir + "mobilenet.h5", 
        monitor='val_categorical_accuracy', verbose=1, 
        save_best_only=True, mode='max'
    )
callbacks = [checkpoint]
model.fit(
    training_data_generator,
    epochs=20,
    validation_data=validation_data_generator,
		callbacks=callbacks
)

Thanks to this, we managed to reduce the number of wrong orientations from 13.5% to 2.5% on our 1000 test tickets.

Extract the text

The following step was to extract the text from the image. This is the OCR (Optical Character Recognition) part. For this, we used the docTR package from Mindee. DocTR divides the task into two parts: first text detection (isolate words regions), then text recognition (identify characters). We use the default pretrained detection and recognition models provided by docTR.

from doctr.models import ocr_predictor

ocr_model = ocr_predictor(pretrained=True)

Find the requested weight

The next step was to find the good weight among all the extracted text. We did this part using token classification. It consists in assigning labels to individual tokens in a sentence. Tokens can be words, letters or subwords. Here we try to identify tokens belonging to two classes:

• O, Outside of a named entity
• W, net Weight entity

For this task we used a LayoutLM model, which is a transformer model that takes into account both the text and the layout of the document. This was done using the Transformers package from Hugging Face.

The LayoutLM model expects tokens and their boxes coordinates as input. So the first part of the token classification step is to build those tokens and corresponding boxes. In our case, tokens will correspond to subwords.

DocTR already gives us words and their bounding boxes.

First, LayoutLM expects the coordinates to be on a 0–1000 scale. Since docTR gives the boxes as relative coordinates, you just have to multiply the OCR result coordinates by 1000.

Then we have to split these words into tokens that match the ones the model has been pretrained on. This can be done by using the tokenizer corresponding to the model given by Transformers.

import numpy as np
from transformers import (
    LayoutLMConfig,
		LayoutLMTokenizer,
)
import tensorflow as tf

tokenizer = LayoutLMTokenizer.from_pretrained("microsoft/layoutlm-base-uncased")

train_features = tokenizer(
    list(train_images_words_data_df["sentence"]),
    padding="max_length",
    truncation=True,
    return_tensors="tf",
).data

Extending the bounding boxes to these tokens must be done manually. This extend must take into account the special tokens that are added by the tokenizer, such as the tokens of start and end of the document, or the padding tokens (that are added so all our documents have the same size and can be processed by batch). We also have to take into account the possible truncation of the document (that is necessary to fit with the model maximum admissible input size). For training, labels must also be extended. We set the labels of all special tokens to -100 (the index that is ignored by the loss function) and the labels of all other tokens to the label of the word they come from.

config = LayoutLMConfig.from_pretrained("microsoft/layoutlm-base-uncased")

# Build boxes and labels for tokens
max_tokens = config.max_position_embeddings

images_token_boxes_list = []
images_labels_list = []
for _, row in images_words_data_df.iterrows():
    words = row["value"]
    normalized_word_boxes = np.transpose(
        [row["x0_scaled"], row["y0_scaled"], row["x1_scaled"], row["y1_scaled"]]
    ).tolist()
    labels = row["label"]
    token_boxes = []
    token_labels = []
    # Words tokens
    for word, box, label in zip(words, normalized_word_boxes, labels):
        word_tokens = tokenizer.tokenize(word)
        token_boxes.extend([box] * len(word_tokens))
        token_labels.extend(
            [label] * len(word_tokens)
        )
    # Truncation
    special_tokens_count = 2
    if len(token_boxes) > max_tokens - special_tokens_count:
        token_boxes = token_boxes[:(max_tokens - special_tokens_count)]
        token_labels = token_labels[:(max_tokens - special_tokens_count)]
    # Add bounding boxes of special tokens([CLS] and [SEP])
    token_boxes = [[0, 0, 0, 0]] + token_boxes + [[1000, 1000, 1000, 1000]]
    token_labels = [-100] + token_labels + [-100]
    # Padding
    padding_length = max_tokens - len(token_boxes)
    token_boxes += [[0, 0, 0, 0]] * padding_length
    token_labels += [-100] * padding_length

    # Add image result
    images_token_boxes_list.append(token_boxes)
    images_labels_list.append(token_labels)

train_features["bbox"] = tf.convert_to_tensor(train_images_token_boxes_list)
train_features["labels"] = tf.convert_to_tensor(images_labels_list)

Regarding the model, we fine-tuned the Transformers LayoutLM pretrained model on 135 tickets. As for the orientation model, these notes were annotated thanks to a home-made annotation tool, also based on OpenCV.

import tensorflow as tf
from transformers import (
    TFLayoutLMForTokenClassification,
)

BATCH_SIZE = 2
EPOCH_NUMBER = 5

train_tf_dataset = tf.data.Dataset.from_tensor_slices(train_features)
train_tf_dataset = train_tf_dataset.shuffle(len(train_tf_dataset)).batch(BATCH_SIZE)

model = TFLayoutLMForTokenClassification.from_pretrained(
    "microsoft/layoutlm-base-uncased", num_labels=2
)
model.compile(optimizer=tf.keras.optimizers.Adam(learning_rate=5e-5))
model.fit(train_tf_dataset, epochs=EPOCH_NUMBER)

Rebuild the weight

After the token classification task, we have some tokens identified as weight. It is worth noticing that along the different steps, the weight can be split in several different words (by OCR task) and into different tokens (tokenization for token classification). In an ideal world, at this step we should just have to paste all the tokens identified as weight together to rebuild our weight. But in reality, this part can be messy.

For instance, tokens that are part of the requested weight could have been predicted as not weight (false negative), and on the contrary some tokens that are not part of the wanted weight can be predicted as weight (false positive). For the first issue, we tried to smooth the prediction by using the box of the tokens identified as weight: we consider that all the tokens inside a box are part of the weight if one is predicted as weight. And so, all the tokens of a box containing a weight token are merged together to constitute a partial candidate string.

Then, to handle the weight split into several words (this can for instance happen when there is a space after the thousands), we use the order of the boxes: if two consecutive boxes are considered as weight, we merge them.

After this, we have several potential weight strings that can contain any character. For each of them, we use a simple regular expression to extract the digits and add some basic business rules to compute a number, check if it can constitute a plausible weight and determine also the unit. We finally select one of the plausible weights.

Results

Thanks to this approach, we managed to achieve an accuracy of 74% on a test set of 1000 weight notes, excluding the 3% of tickets where the weight is not visible at all (weight is not on the picture, extremely blurry).

This result can already be useful for some Dashdoc features, as automatically validating the weight input by the trucker before invoicing, enabling our users to avoid opening the document to check it manually before making the invoice.

Here we built the frame of our solution, knowing each step can be improved. We could try other models for the orientation classification model. We used the raw models of docTR, but we could train them on our data to see if detection or recognition can be improved. For the weight identification part, we could train the model on more data or try to see if some business rules could be useful. And the final heuristic, which is really basic for now, could also be improved.

Extracting information from documents has become a common issue and the applications are huge. Here we chose a special use case to begin with, but it could be extended to a lot of other subjects at Dashdoc. Technically, it covers different very interesting technical domains. Dividing the problem into different parts highlights this and makes it easier to iterate. The results are promising, stay tuned for the next step: integrating the weight extraction features inside the product!

Extracting structured data from scanned documents was originally published in Dashdoc on Medium, where people are continuing the conversation by highlighting and responding to this story.