An Austrian agritech startup and the economics of idle machinery
The client is an early-stage agritech company in Austria whose founders had watched the same pattern repeat across small and mid-sized farms: expensive equipment sits unused for most of the year, produce is sold through slow intermediaries, and the farm two valleys over has no easy way to say “we have a baler free this week.” They wanted a single digital space where machinery rental, produce trading, and farm-to-farm collaboration all happen against verified identities and real availability. Sigi Technologies took the project from discovery through launch.
At the client’s request, the startup’s name, store listings, timeline, team size, and usage figures are not published here; the product itself and the engineering decisions behind it can be described in full. Those decisions draw on the same playbook as our ServiPR services marketplace and our broader mobile app development work.
The problem: manual rentals, thin trust, and patchy rural connectivity
Before the platform, a machinery rental between two farms was a phone call, a handshake, and an argument about diesel. The founders framed the gaps to solve as four distinct pain points, and each one shaped a part of the architecture.
- No unified place for farmers and equipment owners to find each other — listings lived in group chats, noticeboards, and memory.
- Rentals and produce sales ran on manual, time-consuming processes: agreeing dates by phone, settling cash on collection, no record if a machine came back damaged.
- Limited trust and transparency in peer-to-peer deals — nobody could verify who they were dealing with or whether payment would actually clear.
- Rural connectivity: the people using the app are in fields and barns where mobile signal drops, so a network-dependent app would fail at the exact moment a booking needed confirming.
The stack we built it on
The agritech marketplace runs as a Flutter app on iOS and Android, with Kotlin and Swift modules where the platform demanded native work — background sync, location services, and the on-device caches that make offline use possible. Behind the app sits a set of Node.js services split by domain: listings and search, bookings and availability, payments and payouts, identity and messaging. PostgreSQL is the system of record for listings, bookings, and users, with geospatial indexing over listing coordinates; Redis holds the hot data the app must feel instant on — nearby-search results, availability state, and session data.
Location-based matching is the heart of the product. Every listing carries geocoded coordinates, and the matching engine ranks candidates by proximity first, then by cost and by the owner’s reliability rating, so a request for a seed drill surfaces the closest well-reviewed machine rather than the cheapest one three hours away. Distance-based pricing is computed from the same data. This is the same location-first approach we take in our on-demand platform work, applied to tractors instead of couriers.
How the platform is built and run
The agritech marketplace is engineered to make peer-to-peer deals trustworthy where the mobile signal drops — one data model, hard rules on availability, and an offline-first client:
- Offline-first Flutter apps: a farmer can browse cached listings, draft a booking request and read chat history without signal, and the request is queued and sent by background sync on reconnect, with native Kotlin and Swift modules handling background sync, location services and the on-device caches.
- Node.js services split by domain — listings and search, bookings and availability, payments and payouts, identity and messaging — talking gRPC internally with typed Protocol Buffer contracts and REST over HTTPS to the apps through an API gateway that translates between the two.
- PostgreSQL as the system of record for listings, bookings and users with geospatial indexing over listing coordinates, and Redis for the hot data the app must feel instant on — nearby-search results, availability state and sessions.
- Proximity-first matching: candidates are ranked by distance, then by cost and the owner’s reliability rating, with distance-based pricing computed from the same coordinates.
- Availability enforced in the data, not just the UI: one confirmed booking per machine per window rejected at the database level, expiring holds on requested windows, owner-blocked dates, return-to-close on completion, and real-time availability pushes that invalidate cached search results.
- Escrow-style payments on Stripe with payout held until both sides confirm, Twilio phone verification with SMS fallback, KYC required before anyone can list or receive a payout, and two-way ratings feeding the matching engine’s reliability score.
- Containerized services provisioned with infrastructure as code, observability wired in from the first deployment, and builds, tests and releases run through automated CI/CD on GitLab.
What we implemented: farmer app, booking engine, and admin console
Sigi designed, built and shipped the marketplace end to end. Here is what we implemented across the farmer app, the booking engine and the admin console.
Farmer app: three marketplace listing types
A single account can act as owner, renter, seller, and buyer, so the app organizes everything around listings rather than roles. Three listing types share one flow for photos, location, pricing, and availability, and diverge only where the deal type demands it.
- Rental listings — machinery and attachments offered by the day or the job, with an availability calendar, distance-based pricing, and optional operator included.
- Sale listings — produce and surplus inputs traded with bidding, so buyers can offer on a lot, plus logistics coordination for collection or delivery once a bid is accepted.
- Collaboration listings — labor swaps, shared transport, and joint equipment purchases between nearby farms, matched by proximity and confirmed in-app without a payment leg.
The whole app is multilingual, and the offline-first design means a farmer can browse cached listings, draft a booking request, and read chat history without signal; the request is queued and sent by background sync when the phone reconnects.
Booking flow and equipment availability tracking
Availability is where a farm machinery rental marketplace breaks if it is handled casually. A machine that appears free but is actually out on a job costs the owner a reputation and the renter a harvest window. The booking service enforces a small set of rules that every path through the app respects.
- One confirmed booking per machine per time window — overlapping confirmed bookings are rejected at the database level, not just in the UI.
- A booking request places a temporary hold on the window while the owner reviews it; the hold expires automatically if the owner does not respond, releasing the slot.
- Owners can block dates for their own use, and blocked dates never appear as bookable to renters.
- A rental only closes when the owner marks the machine returned; until then, the next window stays unavailable and the escrowed payment stays held.
- Availability changes are pushed to the app in real time, and cached search results are invalidated so a renter never books against stale data.
Secure transactions: Stripe escrow, Twilio verification, KYC, and ratings
Trust between strangers was the client’s hardest requirement. Payments run on Stripe in an escrow-style pattern: the renter or buyer pays at confirmation, funds are held by the platform, and the owner or seller is paid out once both sides confirm completion. Twilio handles phone verification at sign-up and the SMS fallback for booking alerts when a push notification cannot reach a device in the field. Identity verification (KYC) is required before anyone can list machinery or receive a payout, in-app chat keeps negotiation inside the platform, and two-way ratings after every completed deal feed back into the matching engine’s reliability score.
Admin console
- User and listing management, including KYC review queues and the ability to suspend an account or a listing.
- Payout control — release or hold escrowed funds, review disputes, and reconcile against Stripe.
- Pricing policies: platform fee rules, distance-pricing bands, and regional settings that apply platform-wide without an app release.
Delivery and engineering practice
Sigi’s end-to-end team ran product discovery, UX/UI design, backend and mobile development, QA, and analytics as one squad. The services are containerized and provisioned with infrastructure as code, with observability wired in from the first deployment so booking and payment failures are visible before a farmer reports them. Builds, tests, and releases run through automated CI/CD on GitLab. That setup mirrors the approach described in our DevOps and cloud services.
The team and expertise behind the build
The marketplace was delivered end to end by one cross-functional Sigi team — product strategists, UI/UX designers, mobile and full-stack engineers, and QA — working as a single unit rather than handing the build between vendors. Sigi hires only specialists: every engineer is an expert in their own field, and we invest in the team as they deliver, supporting certifications and continuous learning so expert, motivated engineers stay on every build. It is the model we have run since 2016: deep, cross-industry expertise owning the whole stack, from the offline-first Flutter apps and the native Kotlin and Swift modules to the gRPC-linked Node.js services, the PostgreSQL geospatial data model, and the Stripe escrow and KYC layer. Making peer-to-peer deals trustworthy and usable where the mobile signal drops is exactly the kind of demanding, full-stack engineering our team is built for — the same capability behind our mobile app development and custom software work.
What shipped
The agritech marketplace launched with Flutter apps on iOS and Android, an admin console, and a Node.js backend behind them. In the apps, that means the three listing types under one flow, proximity-first matching with distance-based pricing, a booking engine with holds, blocked dates, and return-to-close, escrow-style Stripe payments with KYC gating on listings and payouts, Twilio phone verification with SMS fallback, in-app chat, and two-way ratings — all of it usable from a cached copy when the signal drops, with pending requests replayed on reconnect. The console gives the client’s team KYC review, payout and dispute control, and pricing policy changes without an app release.
Related marketplace and on-demand work
If the pattern here is familiar, the closest builds are the VinCash sell-your-car platform, where listings and verified transactions also carry the product, the food and grocery delivery platform, which shares the Flutter-plus-Node.js-plus-Redis foundation, and the Busy Bean Coffee ordering platform, another multi-party build where Stripe splits payouts between more than one seller. Planning a rental or peer-to-peer marketplace of your own? Talk to Sigi about scoping it — or read more about our custom software development practice first.
