Software · MVPs · Automation

Practical software that keeps working when it matters.

I’m Jesper Nybøle Toustrup, the developer behind NyboleDigital. I build small software products, MVPs and automations – and I test them on real devices, with real users, until they hold up. AI-assisted development lets me move fast. Disciplined testing makes the result trustworthy.

Try the live demo Have a project in mind?

10 external testersran Camper BU22 overnight on their own phones in beta round 1

6 languagesin the Camper BU22 0.4 beta: EN, DA, DE, FR, ES, NL

74 / 74 checksautomated post-boot verification on the OTTO Android 17 build

What I work on

Small, focused builds that solve one real problem well.

I take an idea from a rough description to something that runs, can be tested and can be shown to customers – with clear documentation of what works and what doesn’t yet.

Android apps & device automation

Native Android with Kotlin, background scheduling, AccessibilityService automation and apps that must run unattended for hours.

MVPs & interactive prototypes

From idea to something you can click, test and show to customers or investors – fast, honest about its limits and well documented.

Workflow & AI automation

Email triage, data extraction and follow-ups with tools like n8n, OpenAI and Google Sheets – with a human approval step where it matters.

Embedded Android & diagnostics

Custom Android builds, flashing and recovery tooling, boot diagnostics and integration with in-car displays.

AI-assisted development

AI writes code fast. I decide what ships.

I use AI coding tools – mainly Claude Code – as a fast, tireless pair programmer. I stay responsible for what matters: the requirements, the decisions, the testing on real hardware and what is released.

Requirements first. Decisions are written down and versioned – e.g. “restart every 28 minutes, never below 25”.
Evidence over assumptions. Every fix is traced to a log line, a measurement or a line of code – not a guess.
Real-world testing. Night logs from external testers on different phones, not just an emulator.
Honest status. Nothing is called done or validated before it has been tested. Limitations are documented.
Privacy by default. Diagnostics collect structure and event codes – never screenshots of other apps or personal data.

Selected work

Three real projects – from an Android beta to embedded systems.

Each case below explains the problem, the technical approach and the current status – including what is not finished yet.

Camper BU22 home screen: temperature 21.0°, start at 00:30, end at 07:00 and a battery forecast

0.4.0-beta · final beta testing

Camper BU22

An Android app that keeps an electric camper van’s parked climate running all night by operating the official VW app through Android Accessibility.

Android
Kotlin
AccessibilityService
Field testing

Try the demo Read the case

AI secretary demo overview with new enquiries, unanswered quotes and draft follow-ups (fictional data)

Concept demo

AI secretary for trade businesses

An interactive sales demo of a “digital secretary” that sorts incoming email, extracts customer details and prepares follow-up drafts for the owner to approve.

Prototype
UX
n8n · OpenAI (planned)

Read the case

Completed · personal R&D

OTTO

Android 17 on an Ottocast car box: CarPlay video to the car screen and Google Maps turn-by-turn arrows in the instrument cluster.

Android 17
Qualcomm EDL
Python
SELinux

Read the case GitHub

Interactive simulation – no live vehicle connection

Camper BU22 – try it in your browser

This is a working simulation of the real app’s night logic: choose a temperature and times, start a session, and watch the 28-minute restart cycle, verification, retries and the event log. No Android phone, VW account or car needed.

21:45Simulation

Camper BU22

Ready

Inside temperature

21,0°

16.0° – 29.5° in 0.5° steps

Start

End

07:00

–

Battery forecast–

–

Model from documented test nights · simulated weather

See a whole night in about 25 seconds

Starts a session now with your settings and fast-forwards to the end time. Add a simulated VW hiccup to watch the retry logic work.

Speed

Sim clock: –
Climate: –
Next restart: –
Restarts: –

––

Verified startFailed startClimate stopped by carNight temperature

Event log

The simulation runs entirely in your browser and sends nothing anywhere. Timing rules, log codes and the battery model come from the real app’s 0.4.0-beta source and documented 0.3.x night logs; the car, the weather and the VW app are simulated.

Case 1 · Android

Camper BU22: an all-night climate assistant for EV campers

An Android app that does what a half-asleep person would otherwise have to do every half hour: restart the parked climate in the official VW app.

My role: Idea, development, testing, support
Platform: Android 12L+ · Kotlin
Status: 0.4.0-beta
Testing: Own car + 10 external testers

The problem

A VW ID. Buzz from model year 2026 or earlier runs its parked climate for about 30 minutes and then switches off. There is no built-in camping mode in those model years, and VW’s API is closed to third-party apps. Sleeping in the van on a cold night means waking up every half hour to restart the heating.

The approach

Camper BU22 runs on an Android phone left on a charger in the car. Every 28 minutes it opens the official VW app, checks the current state and restarts the climate – through Android’s AccessibilityService, exactly like a person tapping the screen. There is no API hack, no reverse engineering of VW servers, and the app never stores VW login details.

How one restart cycle works

SchedulerAn exact alarm fires every 28 minutes (or exactly at a night-temperature switch). A wake lock keeps the phone awake.
Open the VW appThe service launches the VW app and waits until its home screen is verified from the UI tree.
Find the climate controlElements are found by resource IDs and node structure – not pixel coordinates – so it works on any screen size.
Stop → verify → start → verifyIf the climate is still running it is stopped first, then started again. Every tap is confirmed by reading the result back.
Log and returnThe result is logged with a code and time, the next restart is scheduled and the phone goes back to the dark night screen.

Engineering behind it

Android AccessibilityServiceReads the VW app’s accessibility tree and acts on nodes, the same way assistive technology does.
Integration through an existing UINo API access needed. The app works with the official VW app the user already has installed.
Calibration per deviceA one-time speed test picks a timing profile (FAST / BALANCED / SAFE). Temperature uses the slider’s neighbour values, so one tap is exactly 0.5° on any phone.
Automatic session controlStart now or at a set time, end time, night temperature, range guard and recovery after a phone reboot.
Timing and scheduled actionsExact alarms, wake locks and an extra restart exactly on the night-temperature boundary instead of up to 28 minutes late.
Verification of every actionStart and stop are only counted when the VW app’s UI confirms the new state – typically within 60–80 ms.
Retry logic and error handlingRetry after 1 minute (3×), then every 5 minutes. 0.4 adds loop caps, an 8-second no-progress watchdog and VW outage detection.
DiagnosticsA structured event log with codes such as RUNNING_VERIFIED or E_START_NOT_VERIFIED that testers send with one tap. It holds no screenshots of the VW app and no car location.
Testing with external usersRound 1 ran on Google Pixel, Samsung, Xiaomi, OnePlus and Lenovo devices. Every log was analysed and turned into fixes.

Developed iteratively

Concept
Could a phone do the half-hourly restart? The API route was ruled out because VW requires device attestation since mid-2026.
Prototype
An accessibility service that finds the climate control and toggles it, plus calibration of tap timing.
Test
Night tests in my own car, logs pulled every morning, then external testers on other phones.
Failure analysis
Example: rare 60-second hangs were traced to a loop between two VW screens after an optional battery reading. The root cause was confirmed in the code.
Improvement
A loop cap, an 8-second watchdog and adaptive per-device patience. The interval went from 29 to 28 minutes for a 2-minute safety margin.
Beta
0.2 → 0.3.2 with 10 external testers. 0.4.0-beta adds six languages, in-app help and the robustness fixes.

Current status

Version 0.4.0-beta – final beta testing before 1.0

0.4 is built and contains the fixes from round 1, but it is not validated yet. Night tests and the next external tester round are still pending. 0.4 results will be published here separately when they exist.

Earlier results from documented 0.3.x night logs, anonymised. These builds used a 29-minute interval; 0.4 uses 28 minutes. “Self-healed” means the next scheduled cycle recovered without user action.
Night	Build	Device	Duration	Result	Notes
A	0.3 dev	Google Pixel	3.4 h	✓ 7/7 restarts verified	Delayed start fired on time; night temperature switch worked. Battery used 5 % vs 4 % forecast (outside 4 °C).
B	0.3.1	Google Pixel	3.5 h	✓ 8 restarts, completed	Night-temperature switch at 01:00 OK; a VW pop-up was dismissed automatically.
C	0.3.2	Xiaomi	4.5 h	✓ Completed	Target temperature held all night (outside 7 °C, car charging). 3 unconfirmed starts, all self-healed.
D	0.3.2	Xiaomi	3.5 h	✓ Completed	Cold night (1 °C), not charging: 1.43 % battery per hour, forecast 5 % = actual 5 %. 5 short hangs, all self-healed.
E	0.3.2	Lenovo tablet	8 h	✓ Completed	3 × 60-second hangs, all self-healed – the main input for the 0.4 watchdog fix.
F	0.3.2	Google Pixel	~2 h	✓ Session clean, 4 restarts	First-time calibration took 43 minutes on this phone, which led to clearer feedback and faster escape in 0.4.

0.4.0-beta results

Pending – no 0.4 results are claimed yet. Planned before 1.0:

Night tests on my own car with the 28-minute interval.
External tester round with sign-up, incl. testers outside Denmark.
Verification of the new languages and VW app version coverage.

Feature status – what is tested, built or planned

Tested in practice (0.3.x nights)

Restart cycle with verified Stop → Start (then every 29 min)
Delayed start and exact night-temperature switch at 01:00
Battery forecast vs actual use (5 % = 5 % on a cold night)
Automatic dismissal of harmless VW pop-ups
Self-healing retries; calibration on five phone brands

Built in 0.4.0-beta – awaiting test

28-minute restart interval
Loop cap, 8-second fast escape and adaptive per-device patience
“VW not responding” outage detection with a plain message
Six languages and in-app help/FAQ
Animal mode (beta) – built, not yet validated in a documented test

Planned – not in 0.4

Public 1.0 release
In-app update notification
Cabin-temperature reading and remote alerts for animal mode
1.0 without the per-session log prompt used during the beta

Real screenshots

Screenshots from the 0.3.x beta (Danish UI) on a Google Pixel. The 0.4 interface is similar and also available in English, German, French, Spanish and Dutch.

Safety, privacy and honest presentation

Animal mode is not a safety system. Animal mode (beta) raises alarms immediately and keeps the screen on, but the app can fail – no internet, a locked phone, a VW outage or a changed VW app. It must never be the only safeguard for animals or people in a vehicle. Always check the temperature yourself and stay within reach.

Not a Volkswagen product. Camper BU22 is an independent hobby project. It is not made, endorsed or approved by Volkswagen. It works with the official VW app that the user already has.

No public download. 0.4-beta is only distributed through a controlled beta test with a separate sign-up. It is not available from this website. A public 1.0 release is planned for later.

Depends on VW’s app and servers. If VW’s servers are down or the car loses its connection, no app can restart the climate, and it stops after about 30 minutes. 0.4 detects this and tells the user plainly instead of failing silently.

Case 2 · Automation

AI secretary: no customer enquiry overlooked, no quote forgotten

A tradesperson’s inbox is full of enquiries, supplier mails and noise, and quotes without a reply are easily forgotten. I built an interactive concept demo that shows how an AI secretary could work invisibly in the inbox they already use.

My role: UX, prototype, technical plan
Platform: HTML/JS demo · n8n + OpenAI plan
Status: Concept demo (simulated AI)
Testing: 101/101 automated checks

What I built

A self-contained, offline sales demo (one HTML file) that walks through the full flow in 60–90 seconds, plus a 73-second screen recording and a written technical delivery plan.

Email triage: customer enquiries, customer replies, suppliers and noise.
Extraction of name, phone, address and task – with “Not provided” instead of guessing.
Follow-up drafts for quotes with no reply after 4–5 days.
Nothing is sent without the owner’s approval. Uncertain cases go to manual review.

Technical plan for a real MVP

n8n as the workflow engine, Gmail via OAuth, OpenAI with a fixed JSON schema for classification and extraction, and Google Sheets as the overview. The known risks are mapped with mitigations: thread matching, replies by phone, GDPR and data processing agreements, and AI misclassification.

Testing

101 of 101 automated checks passed in a simulated browser DOM. The layout was checked in Chromium at 390×844 (mobile), 1366×768 and 1920×1080, with fixes for mobile overflow and touch targets.

Honest status: this is a concept demo. The AI and email integrations are simulated. The real MVP is scoped and planned, but not built.

Case 3 · Embedded Android

OTTO: Android 17 on a car box, integrated with a VW ID. Buzz

An Ottocast P3 Pro car box moved from its stock Android 13 to an Android 17 system image while keeping the original CarPlay chain. In the car it shows Google Maps as a home screen through a custom launcher, streams it to the car screen as CarPlay video and sends turn-by-turn arrows to the instrument cluster.

My role: Everything – personal R&D
Platform: Qualcomm SM6225 · Android 17
Status: Completed, running in the car
Testing: Bench + in-car test plan A–G

Instrument cluster showing a navigation arrow and street name from Google Maps — Turn-by-turn arrow in the instrument cluster (test route)

Custom flashing toolThe USB connection dropped at 130–260 MiB. I wrote a writer that streams 1 MiB per command, waits for acknowledgement and reads back to verify.
Reproducible image buildsBuild scripts with exact file modes, owners and SELinux labels, verified byte by byte against the image.
VerificationA 74-point post-boot check with SELinux enforcing and zero denials, plus an in-car acceptance plan.
Performance60 fps projection measured in the car with a dedicated test pattern.
Recovery firstAn EDL rescue runbook and a fallback image. A failed OTA experiment is documented openly as an incident report.
Shared with the communityA public build write-up with guides for others, with keys, firmware and private data kept out.

OTTO shows the low-level side of my work: debugging hardware that fails in unclear ways, writing my own tools when existing ones don’t hold up, and documenting what doesn’t work as carefully as what does.

OTTO source, evidence and guides on GitHub

Contact

Have a project in mind?

I’m looking for well-defined projects where a small, focused build makes a real difference. I work remotely in English and Danish.

Smaller software projectsApps, tools and web pages with a clear purpose and scope.
MVP developmentA first version you can test with real users or show to investors.
Automation tasksEmail, data and workflow automation – with human approval where it matters.
Free hostingStatic websites and demos that I build can be hosted on free infrastructure such as Cloudflare Pages, with no hosting bill for you.

Or write directly: jesper@stabilt-wifi.dk