Both halves of your vertical software. Field app and back office, on the same data.
Your customers are waiting on a feature that has to work in the office and in the field? I build both sides with your team, and they share the same data. The app keeps working when the signal drops.
Teams I've worked with
Your customers are waiting on the next feature.
It has a deadline: a trade show, a date you gave a key customer, or a legacy system's shutdown. Your team knows the product and what to build. Right now, nobody on your team can take it on.
-
You made your customers a promise.
You've committed to a feature, maybe by the next trade show. I help you keep that promise. You and your team decide which part I take on.
-
Your team is stretched thin.
They support customers and keep the product running. There's no time left for the new feature, so I build it with them.
-
Two halves that have to fit together.
The new feature needs both: an office view and data capture in the field app. I build both sides on the same data, so they fit together.
One data source, two interfaces.
Vertical software has two halves. In the office, your users plan jobs and work through long lists of records. Out in the field, someone records what happens on site, phone in hand and short on time.
I build both interfaces in FlutterFlutterGoogle's framework for building iOS and Android apps and web UIs from one codebase. One team ships both platforms from the same code, and both stay in step.More in the glossary → from one codebase: the same data models, the same connection to your backendBackendThe part of a system that runs in the background on a server: storing data, enforcing rules, connecting services. The app is the surface, the backend is the machine behind it.More in the glossary →. I design the screens for the office and the field separately. Whatever the office creates, the field crew sees. Whatever the field crew records, the office sees.
- Shared data models and validation rules
- One connection to your backend
- Separate interfaces for office and field
What clients say.
“Julian provides accurate estimates and high-quality results. His personal commitment to quality customer work completes the picture of a professional contractor.”
Nikolaus Reinartz Managing Director, RK Vision Homes GmbH “I recently had the chance to work with Julian on a really exciting project where the app and the website were seamlessly connected … Working with him was positive throughout: reliable, professional, and genuinely pleasant. Julian thinks ahead, communicates clearly, and delivers cleanly structured results. Thanks to his well-thought-out implementation, I could focus entirely on the web integration. The interfaces were easy to follow, stable, and well documented.”
Daniel Nilges Web development, Codeäffchen Features almost every vertical product needs.
You'll usually need dispatch, master data, and field data captureField data captureRecording data in the field with photos, location, NFC, and timestamps, even without a connection.More in the glossary →. I've built these building blocks for clients since 2020. So on your project, I can focus on what only your product does.
- Construction
- Automotive
- Insurance
- Security services
- Real estate
- Events
-
Dispatch
The office plans and assigns jobs, and the field crew works through them.
-
Master data
The office maintains customers, sites, and products. Field crews have them on their device.
-
Field data capture
Forms and checklists guide your users through each job, step by step.
-
Photos and camera
Your users take a photo in the app, and it attaches straight to the record.
-
Location and NFC
The app tags each entry with its location via GPS, or its asset via NFCNFCNear Field Communication: short-range radio that works within a few centimeters. A phone reads a chip on a machine, a door, or a badge. From each scan, an app can tell what someone is working on, and where.More in the glossary →.
-
Sign-in
Everyone sees only what their role allows. I use the sign-inAuthenticationChecking who is signing in, whether by password, code, or a link sent by email. For apps there are ready-made services like Firebase Auth, Supabase, or Appwrite that handle this securely.More in the glossary → your product already has. If there isn't one, I build it with FirebaseFirebaseGoogle's bundle of services for apps: database, sign-in, file storage, push notifications. It saves you from running your own servers, but it ties you to Google.More in the glossary →, SupabaseSupabaseAn open-source alternative to Firebase, built on PostgreSQL. You can host it yourself, for example on servers in the EU.More in the glossary →, or AppwriteAppwriteAnother open-source platform for app backends, with sign-in, database, and file storage, that you can run on your own infrastructure.More in the glossary →.
Capture data where the work happens.
In basements, on construction sites, or in parking garages, the signal drops. The app is offline-firstOffline-firstThe app works without a connection and syncs as soon as it's back. Entries land on the device first, so nothing gets lost.More in the glossary →: it saves every entry on the device, then syncs once the signal is back. Your users keep working, signal or not.
Syncing can hit snags: two edits to the same record, or an expired login. The app shows what hasn't synced yet and keeps the data on the device until it goes through. We agree up front on which version wins in a conflict.
For field work, I design large tap targets that work with gloves on, and flows with few taps.
- Saved on the device first
- Synced as soon as there's a signal
- Shows what hasn't synced yet
Getting started on your project.
I work in your repoRepositoryThe place where a project's entire source code lives together with its history, usually on GitHub or GitLab. Anyone with access sees every version and every change.More in the glossary →, with your team's tools. First I get to know the code, the architectureArchitectureHow the software is divided into parts. It decides whether the next feature is easy or expensive.More in the glossary →, and how releasesReleaseA version of the app that reaches its users, usually through the App Store or Google Play.More in the glossary → ship. Then I take on the feature your customers are waiting for.
- 1
A call
Thirty minutes over video. You tell me which feature is coming up and how your office and field teams work together today. I tell you if I can help, and how.
- 2
Starter phase
The starter phase is fixed-price, with a defined deliverable: one feature, released in the app and the web app.
- 3
In your sprint
After that, I keep working in your sprintSprintA fixed stretch of work, usually two weeks. The team commits to a goal and shows a result at the end. Then it plans what comes next.More in the glossary →, one feature at a time. Your team approves every change in code reviewCode reviewA second pair of eyes before code is merged. Bugs show up early, and knowledge spreads across the team.More in the glossary → and can maintain the code on its own.
How I think about field and office apps.
One shared codebase in Flutter
Why app and web interface can be one project.
Read more No connectionOffline handling in Flutter apps
What happens when there is no signal in the basement.
Read more ArchitectureMoving large features out
How large features move into their own packages so the app stays maintainable.
Read moreQuestions about vertical software.
Who do you build vertical software for?
I build vertical software, such as field service tools, together with teams that own their software product. That software usually has two halves: a web app in the office and an app in the field. I'm Julian Giesen, a senior software engineer based in Dinslaken, Germany. I work as part of your team, in Flutter for most clients, remotely or on site.
Does the app work offline?
Yes, the app works without a signal. I build it offline-firstOffline-firstThe app works without a connection and syncs as soon as it's back. Entries land on the device first, so nothing gets lost.More in the glossary →: every entry lands on the device first. Once the signal is back, the app syncs and shows what hasn't synced yet. If two users edit the same record, a rule we agree on up front decides which version wins.
Can the app connect to our existing backend?
Yes, I connect the app to your existing backendBackendThe part of a system that runs in the background on a server: storing data, enforcing rules, connecting services. The app is the surface, the backend is the machine behind it.More in the glossary →. Both the field app and the web app call the APIsAPIAn interface two programs use to talk to each other, such as the app and the server. It defines which data you can request and send, and how.More in the glossary → your product already has. If one is missing, I build it with your team, for example in KotlinKotlinThe language for native Android apps, also used on the server. It shows up for Android-specific features and for backend services.More in the glossary → or Node.jsNode.jsJavaScript on the server. A good fit for lean services and APIs that feed an app with data.More in the glossary →.
What tech stack do you use for vertical software?
I build most field apps in Flutter and the rest natively in Swift or Kotlin. With Flutter, the field app and the office web app come from one codebase. If your web app already runs on React, for example, I build on it. On a call, I'll tell you what fits your product.
Which industries have you worked in?
I've worked on projects in construction, automotive, insurance, security services, real estate, and events. The building blocks are usually the same: dispatch, master data, and field data capture.
Let's talk about what your office and field teams need next.
In thirty minutes, you tell me which feature you've promised your customers. I'll tell you if I can help build it, and how.
- Video call, no prep needed
- Reply within one business day