Surf found the app inside the paperwork.

The revealing detail in Surf’s KFC case study is a calendar. Restaurant managers made schedules in Excel, then copied them into Google Calendar or Outlook. Checklists lived on paper. Clock-in records moved by hand from a log into another system. Here was a business surrounded by software, still asking people to carry information between its disconnected parts.

Surf built Digital Successful Routine, or DSR, to connect that work: reporting, scheduling, tasks and performance dashboards. The company reports that automated routines saved shift managers 10 hours a week. That is a useful way to judge an enterprise app. Count the hours someone gets back.

01 / The phone was already in the pocket

For KFC’s management app, the device mix created an awkward little puzzle. About 95% of expected users owned Android phones. Important managers used iPhones. An Android-only app would mean buying some people another handset. Separate native apps would mean maintaining two implementations.

Surf proposed Flutter, Google’s cross-platform framework, so both groups could use their own phones. The team visited restaurants, watched managers work and interviewed employees. Different roles received different dashboards and access rights. The checklist interface could be described by the server, allowing forms to change through an administration panel. Corporate single sign-on and a security audit were part of the job.

The lesson travels well: inventory the phones before choosing the technology. A tiny minority of users can carry a large share of the operational responsibility.

02 / A business built around other people’s problems

Surf began in 2011 with three university friends: Vladimir Makeev, Roman Tikhonov and Vladimir Kotov. They liked windsurfing, which supplied the name. Early Android work grew into a broader delivery business, adding design, iOS, testing and project management.

One early experiment was charmingly modest. After building an augmented-reality engine for a client, the team reused the knowledge in Park Me Right, an app for finding a parked car. Its published history puts development at roughly $3,000 and marketing at $200. The company says downloads passed 100,000. The copyable move was reusing something already learned.

Today, Surf sells bespoke engineering to organizations that need more than a downloadable template. Its public client references include KFC, Mars, SAP and Burger King. Its services run from customer research and interface design through backend integration, testing and support. A buyer can arrive with an existing product as well as an empty brief.

03 / The bank that needed a translator

A banking project exposes another side of that work. The new mobile application needed to communicate with older backend services using Burlap XML, while the new architecture used JSON. Surf inserted middleware: a translator between systems that spoke different languages.

That let the bank replace old modules gradually. The migration also preserved existing customers’ registrations, so installing the updated app did not send them through enrollment again. These are quiet features. A customer cannot admire the translator. They notice when their account still opens.

The bank intended to take development in-house. Surf helped with technical interviews, shared reviews and joint feature development. Its published account says the use of a standard, publicly available architecture made transfer easier. For a buyer, that changes the procurement question: ask how the engagement ends while discussing how it begins.

“We don’t just do projects”Vladimir Makeew, in Surf’s company history

04 / The price of joining things up

Surf’s Clutch listing gives a $25,000-plus minimum project size and hourly rates of $50 to $99. Those are directory figures, rather than a quotation for your particular application. They place this business in the market for commissioned software, where discovery, integrations and continued maintenance belong in the budget.

The purchasing test is less about counting features than counting dependencies. Who supplies the data? Who can approve a changed workflow? Who answers when an integration behaves differently from its documentation? A development team can write the connector, but the customer still has to supply access and authority. That division of responsibility deserves a place in the brief, alongside the screens.

The alternatives are another development agency, an internal team or packaged software. The sensible choice depends on how peculiar the workflow really is. Repeatedly copying schedules suggests an integration problem. A standard workflow already served by a dependable product may call for buying and configuring it. Bespoke development earns its keep when the surrounding business makes standard software awkward.

05 / A missing feature can change the plan

Surf’s neobank case study contains an instructive reversal. The team planned to use Airship for notifications, then switched to OneSignal because the project needed a notification center the proposed setup could not provide. The useful detail is the requirement that forced the switch. Vendor selection gets real at that level.

That project also needed clearer documentation and delivery routines as the team grew. Surf describes introducing two-week sprints and defined release procedures. Fast iteration depended on quick decisions from the client. If approvals take weeks, the same working rhythm becomes difficult to sustain.

The company’s earlier machine-learning venture offers a bigger correction. Its history says the department closed after roughly three years: gathering and validating data proved more productive inside the client organization. Technical enthusiasm had met an ownership problem. Hiring specialists could not relocate the data’s context.

06 / Leave something the next team can use

Surf’s tools make its engineering habits visible. SurfGen generates code from OpenAPI specifications using templates. Elementary separates interface, presentation and business logic in Flutter applications. Both address the less glamorous costs of software: repetition today, confusing changes tomorrow.

For readers commissioning their own product, the practical sequence is straightforward. Observe the work. Identify where information gets copied. Check the devices and integrations. Preserve customers’ access. Decide who will maintain the result. Surf’s projects are useful because they show those decisions in concrete form. The app is the part people touch; the work around it determines whether it helps.