When mobile apps come up in Gaziantep, people usually think of a shop window. What we build is not a shop window: apps that connect the phone in a field worker's hand to the company's system of record. The sales rep's order, the warehouse count, the technician's service form, the dealer's order, the driver's delivery and the owner's daily summary. We write for iOS and Android from a single codebase, design for offline use when there is no signal, and connect to your existing ERP. The source code stays with you, and we run the work from our office in Şehitkamil — the same city as your factory.
We have built field-facing interfaces before: a B2B dealer portal where dealers enter their own orders, QR menu systems used from a phone, and on the management side an 11-module factory dashboard. What follows is not a fixed menu but the usage patterns we meet most often in the field. A business usually needs only one or two of them; building all of them at once tends to inflate the project and depress adoption. We decide together where to start, after discovery.
In front of the customer, the rep sees the product, the current price, their discount authority and the account balance — and closes the order on the spot. Visit records, routes and collections live on the same screen. With no connection, the order waits on the device and transfers by itself when the signal returns; there is no second entry back at the office in the evening.
Counting, goods receipt and order picking are done with the phone's camera or a handheld terminal's laser scanner. The terminal shows the next location and warns when the wrong product is scanned. For busy, harsh environments a trigger-grip handheld terminal is preferred; for light use, a rugged Android phone — we lay out the difference and the cost openly at discovery.
The work order lands on the technician's phone; the operation performed, the parts used, the time spent and photos are recorded, and the customer signs on the screen. Service history accumulates per device or machine. Warranty disputes then rest on records rather than memory, and on the next fault the technician arrives having read the history.
Your dealer sees stock, their own price list and their account status from their own phone, and enters the order themselves. The order drops straight into your system; the price comes from the list defined in the system, not from a verbal agreement. Dealer-specific prices, quotas and campaign rules are defined in the background; each dealer sees only their own data.
The dispatch list comes down to the driver's phone; at delivery, cartons are scanned, the recipient and signature are captured, and missing or damaged items are flagged with a photo. The office sees the goods confirmed as delivered without waiting for the delivery note to come back. In patchy-coverage areas, records accumulate on the device.
A small number of headings — production, dispatch, orders, collections and critical stock — are gathered on a single screen, with a summary notification at the end of the day. The aim is not to sit the owner down with reports, but to show the pulse of the business in the twenty seconds the phone is out of the pocket. You decide which five numbers live there.
First we determine who will use the app, how many times a day and under what conditions: the sales rep, the warehouse clerk or the dealer. Where possible, we spend a day in the field with that person. Skip this step and you end up with an app that is technically correct and never opened.
Before writing code we prepare a clickable mock-up and walk the single most frequent task end to end. How many taps it takes to close an order becomes clear here. Changes are cheap on a mock-up; the same change in a live app is expensive.
What data lives on the device, which record wins when there is a conflict, and what gets written to the ERP and how often are all agreed in writing. In mobile projects the hard part is not the screens but this; discussed too late, it comes back as inconsistent data.
The app first runs with a team of two or three people in the real field, with the old method kept alongside for a while. Fixes follow the usage data and the users' complaints. We do not recommend rolling out until the pilot team starts using the app willingly.
The app goes live through the App Store and Google Play, or through internal-only distribution; the way it will be used determines which is right for you. Source code, store accounts, setup steps and known limitations are handed over in writing. Afterwards you are in a position to carry it forward yourself.
No — we typically write for both platforms from a single codebase. That simplifies both development and later maintenance; one fix ships to both stores at once. Special cases that need to sit very close to the device (a particular handheld terminal's trigger, a specific scanner) are handled separately on the native side, and we tell you about them at the discovery stage.
Apps meant for the field are designed to work offline from the very start. The user enters the order, does the count, captures the signature; the records wait on the device and transfer when the connection returns. The critical point is the conflict rule: if two people have changed the same record, which one wins is written down in advance. Offline apps built without that conversation produce silent data loss.
No. If the app is an internal tool used only by your own staff, it can be installed via internal distribution without going to the stores; that is usually faster and avoids the review process. For an app your dealers or customers will use, store publication is the right choice. We compare the requirements and timelines of both at discovery.
Both work, but the consequences differ. With personal phones there is no device cost; in return, removing company data from the device when someone leaves, version differences and full phone storage all need rules set from day one. With company devices, management gets easier and costs rise. We look at how many people will use it and how intensively, and give our recommendation at discovery.
That is the goal. On backbones like Logo, Mikro or Netsis, or on legacy software written specifically for the company, we first examine which route the integration should take: is there a ready-made service, will it go through the database, or will a file-based bridge be built? If integration is not possible or is risky, we say so before the project starts — not as a surprise afterwards.
The deciding factor is not the number of screens but the number of flows and the depth of integration. There is a serious difference between a simple field app that does one job and a multi-role system writing two-way into the ERP. That is why we split the work into stages: discovery and mock-up, pilot release, roll-out. Scope and price are fixed as each stage starts, and at the end of each stage the decision to continue is yours.
We take that risk seriously, because most of the failures we see in the field are not technical — they happen for exactly this reason. The antidote is in the design: the app is built to shorten the user's existing work, not to add to it. If someone is expected to write on paper and then also enter it into the app, the design is wrong. We prefer to run the pilot with the most reluctant user; the measure of success is that they are still using it in week two.
We insist it is opened in your company's name. If the developer is the app's publisher, moving the account later and preserving reviews and download history becomes difficult; that is a dependency built without anyone noticing. Source code, database and documentation are also handed to you, and you pay no per-user monthly rent. If you want us to continue, let the reason be satisfaction, not obligation.
Let's discuss the app next to the person doing the work, not over screenshots. We join your sales rep on the route, pick up the device in your warehouse in Başpınar, and establish on site which job is worth moving to mobile. We are in the same city; for this first meeting, all it takes is for us to get on the road.
