Skip to content
F funtology_

Approach

How we work

A fun approach to technology is not about jokes. It is about taking the friction out of building software, so the work stays enjoyable and the result stays useful.

  1. 01

    Listen first

    Before anything gets built we want to understand the work your software has to carry. Who uses it, where it hurts today, what happens on the day it breaks. Most of the value of a project is decided in that conversation, not in the code that follows.

  2. 02

    Ship small working increments

    We deliver in pieces you can actually use. Every increment runs in a real environment with real data, so your feedback is about the thing itself instead of a description of it. Short cycles also mean a wrong turn costs a week, never a quarter.

  3. 03

    Keep it maintainable

    Code gets read far more often than it gets written. We keep ours plain, tested and documented, so the next person can pick it up without an archaeology project. Whether that person is us or someone on your own team is up to you.

  4. 04

    Stay reachable

    A project does not end at launch. You keep the same contact, the same number and the same people who know how your system is put together. Small changes stay small changes instead of becoming a new project.

What "a fun approach" means in practice

Fun is not a mood we add at the end. It is what you get when the obvious sources of misery are removed.

  • No process theatre. No months of discovery before a line of code, no status meeting that exists to produce a status.

  • No surprises on the invoice. You hear what something costs before we build it, and you hear it again if the answer changes.

  • Progress you can see. Something you can click on, early and often, instead of a percentage in a report.

  • Honest answers, including the unwelcome ones. If the thing you asked for is a bad idea, we will say so and suggest the better one.

  • And we enjoy the work ourselves. People who like what they are doing write better software, and that difference ends up in your product.

That sound workable?

Then the next step is a conversation, not a proposal document.

Get in touch