Case by case: the problem, what Appfy did and the gain.
Global furniture retailer
Money in the account, order waiting for a ruler and a pen.
Each paid order only moved once someone found its number on the bank statement, one by one.
The problem
A global furniture retailer sells online to companies, with high-value orders paid by bank transfer. To release each one, an employee laid the order list next to the bank statement and linked the two with a ruler and a pen, with mistakes and sometimes losses. Estimate: 150 orders a day (between 100 and 200) × 3 minutes to find each one on the statement = 7.5 hours a day, one full person just checking; for 4,000 orders a day it would take 25 people (minutes: assumption). Estimate: from 100–200 orders a day by hand to 4,000–10,000 a day, and up to 20,000 on some days.
What Appfy did
Appfy automated the check. As told for this case, the system reads the bank statement every 5 seconds, and each new transfer sets off the check. It finds the order number in the description.
The gain
As told for this case, the check became automatic.
Scene 1 of 8 · The company
Huge orders, paid by bank transfer.
A global furniture retailer sells online to companies, with huge, high-value orders. The company pays by bank transfer and writes the order number in the description.
Scene 2 of 8 · The problem
Two printouts, a ruler and a pen.
An employee laid the order list next to the bank statement and, with a ruler and a pen, linked each order to its transfer. Only then did they mark the order paid in the system.
Scene 3 of 8 · The problem
Every order waited its turn under the ruler.
By hand, they managed 100 to 200 orders a day (estimate), with mistakes and sometimes losses. The money was already in the account, but the order sat still until someone found its number.
Scene 4 of 8 · The goal
The goal: the money lands and the order moves.
Connect the bank account to the orders: find each transfer on its own, check the order number and release the order at once, with no one holding a ruler.
Scene 5 of 8 · What Appfy did
The statement, read every 5 seconds, as told.
As told for this case, the system reads the bank statement every 5 seconds, and each new transfer sets off the check. It finds the order number in the description.
Scene 6 of 8 · What Appfy did
Scene 7 of 8 · What changed
From the ruler and the pen to the automatic check.
Scene 8 of 8 · And in your company?
Does your team still check payments by hand? Connect the bank to your orders.
If someone compares statements and orders to release a sale, Appfy connects the bank to your system, and each exception goes to its own place. Start with a free 30-minute conversation.
Insurance platform (insurtech)
Closing a policy went from two or three days to minutes, right at the counter.
Products were sold with the insurance attached.
The problem
An insurance platform (insurtech) sells through retail stores: phone-theft insurance and insurance for electronics such as fridges, together with the product. But traditionally, closing a policy took two to three days, and the insurance did not fit in the sale. Estimate: 10 insured sales a day in a store × 2.5 days to close each policy (between 2 and 3) = 25 customers per store, at any moment, with their insurance still pending (sales a day: assumption).
What Appfy did
Appfy built the platform's engine: at the start of the day, it sets aside policy numbers for each type of insurance, like a pad of numbered tickets. Each sale gets its number at once, and the engine notifies the insurer, closes the contract, exchanges the policy files with the insurers and analyses the sales.
The gain
Closing a policy went from two or three days to minutes, right at the counter. Products were sold with the insurance attached.
Scene 1 of 8 · The company
Insurance sold in the store, with the product.
An insurance platform (insurtech) sells through retail stores: phone-theft insurance and insurance for electronics such as fridges. The insurance goes with the product, offered at the moment of purchase.
Scene 2 of 8 · The problem
Closing a policy took two to three days.
Traditionally, issuing a policy meant a number, a notice to the insurer, a contract and an exchange of files. All of it took two to three days, and no customer stays that long at the counter.
Scene 3 of 8 · The problem
The phone left the store; the insurance didn't.
Unable to fit in the sale, the insurance waited: the customer took the phone, and the policy came only days later. In a store with 10 insured sales a day (assumption), that means 25 customers, at any moment, with their insurance still pending (estimate).
Scene 4 of 8 · The goal
The goal: buy the phone, leave with it insured.
Close the insurance at the point of sale, together with the product, in minutes, right at the counter. Buying insurance would be as simple as buying the phone, within reach of every customer in the store.
Scene 5 of 8 · What Appfy did
Policy numbers set aside as the day begins.
Appfy built the platform's engine. At the start of the day, it sets aside policy numbers for each type of insurance, like a pad of numbered tickets, ready to use. Each sale at the counter gets its number at once.
With the number on the policy, the engine notifies the insurer and closes the contract. The policy files go back and forth with the insurers, and the sales become analysis: the market and the profile of who buys.
Scene 7 of 8 · What changed
Closing a policy went from two or three days to minutes, right at the counter. Products were sold with the insurance attached.
Scene 8 of 8 · And in your company?
Does your sale still wait days on another company? Close it at the counter.
If a sale of yours only closes once another company answers, with a number, a contract or a file, Appfy connects both ends at the moment of sale. Start with a free 30-minute conversation.
US check-payments company
Taking cards without leaving a toll on every sale.
Taking cards through a ready-made gateway means leaving a toll on every sale; the company wanted to go straight to the source.
The problem
A platform integrates with Rapid Connect (Product of FirstData) to perform payment operations using credit cards. Estimate: a ready-made gateway's public price for a US domestic card sale is 2.9% + US$0.30 (US$3.20 on a US$100 sale).
What Appfy did
Transforming the data to identify patterns of behavior according to test scenarios informed by FirstData. Analyzing the relationships between tags. The fields table lists COUNT 102. Creating the endpoints that collect information from the merchant terminal. Building the structure of the parse and integration factories. Writing integrations tests with jest. Possible test scenarios that we must ensure to become able to obtain a certification. A successful SRS process is needed only once to obtain the DID (Datawire ID).
The gain
Status: Done. Platform that integrates with Rapid Connect (Product of FirstData) to perform payment operations using credit cards. No proven delivered gateway/certification. Unmeasured benefits are never numbers.
Scene 1 of 8 · The company
Checks, transfers and, now, cards.
Platform that integrates with Rapid Connect (Product of FirstData) to perform payment operations using credit cards.
Scene 2 of 8 · The problem
Every card sale would leave a toll behind.
Estimate: a ready-made gateway's public price for a US domestic card sale is 2.9% + US$0.30 (US$3.20 on a US$100 sale).
Scene 3 of 8 · The problem
Going direct means speaking the processor's language.
The processor only opens its door to those who speak its language: 102 possible fields, with rules between them, many kinds of sale and validation, and a battery of test scenarios for certification.
Scene 4 of 8 · The goal
The goal: its own lane, straight to the source.
Platform that integrates with Rapid Connect (Product of FirstData) to perform payment operations using credit cards. Creating the endpoints that collect information from the merchant terminal.
Scene 5 of 8 · What Appfy did
First, learning the processor's language.
Appfy studied each of the processor's test scenarios and mapped the 102 fields: mandatory, optional and which depends on which. With that map, the system receives the card machine's data and assembles each message the way the processor asks.
Scene 6 of 8 · What Appfy did
Register once, keep the key.
Before a merchant can use the Datawire Secure Transport Network to process transactions, the applications needs to go through the SRS process to obtain the DID (Datawire ID). A successful SRS process is needed only once to obtain the DID (Datawire ID); thereafter, as long as DID remains valid, the client app will not need to perform SRS again. Writing integrations tests with jest. Possible test scenarios that we must ensure to become able to obtain a certification.
Scene 7 of 8 · What changed
Its own lane to the source, with no toll.
Status: Done. Platform that integrates with Rapid Connect (Product of FirstData) to perform payment operations using credit cards. No proven delivered gateway/certification. Unmeasured benefits are never numbers.
Scene 8 of 8 · And in your company?
Leaving a margin on every sale? Go straight to the source.
If your company moves payments and hands a middleman a margin on every sale, Appfy builds your direct lane, field by field and tested scenario by scenario. Start with a free 30-minute conversation.
Large pharmacy chain
Merging two pharmacy chains. The design accounts for goods already on their way.
A large pharmacy chain bought another one. Illustration: with about one day of delay in the information, the same medicine could be ordered twice.
The problem
The stores bought would now get goods from the buyer's warehouses. Without seeing what was already on its way, their system could order it all again. Estimate: 391 stores × R$170k in sales a week × 1% ordered twice (assumption) ≈ R$660k a week in idle stock.
What Appfy did
Appfy connected the two systems without replacing what worked: every order got a number, like a tracking code, and the calculation now subtracts what is already on its way.
The gain
A historical engagement to integrate pharmacy-network replenishment after an acquisition. The surviving sources document how demand, warehouse execution, fiscal authorization and store receipt were connected, and the controls proposed for identity, partial quantities and delayed visibility. Measured processing time and realized store scope are absent.
Scene 1 of 8 · The company
One chain bought another. The open question was how to supply the stores it bought.
A large pharmacy chain bought another one. The buyer's warehouses would now supply the stores it bought: like connecting one restaurant's dining room to another's kitchen.
Scene 2 of 8 · The problem
Every order went through many hands before it left.
Every night, a team checks the sales, and the system works out what each store needs and splits the stock. Estimate for the broader processing window, not the allocation step: about 4 to 5 hours. Then come boxes, picking and the tax invoice.
Scene 3 of 8 · The problem
The risk: ordering again what was already on its way.
Example: the store orders 100 and the warehouse has already set aside 80. The store's system only sees this a day later and orders the 100 again, like shopping without checking the pantry.
Scene 4 of 8 · The choice
Keep what works: add two controls.
Appfy fitted the new stores into the operation that already worked. Every order got a number, like a tracking code, and the calculation now subtracts what is on its way.
Scene 5 of 8 · What Appfy did
“Accepted” does not mean delivered.
The two chains used different codes for stores and products, like two languages. Appfy translated between them and named every step of the order: filling only part of it is not an error.
Scene 6 of 8 · What Appfy did
The invoice releases the truck, and the store closes the loop.
The truck only leaves once the government authorizes the tax invoice. At the store, whoever receives it checks boxes and invoice, and that check goes back to planning.
Scene 7 of 8 · What changed
Everyone looking at the same order, by the same number.
The design accounts for what has already left before the next order, and it proposes that the nightly calculation run in parallel per distribution centre. The time after that change was not measured.
Scene 8 of 8 · And in your company?
Restocking, or merging two companies? Start with what is on its way.
If you restock, have merged two operations or connect a new system to an old one, Appfy starts with what is already on its way. Start with a free 30-minute conversation.
The idea was paper work orders on the mechanic's phone.
A mechanic, a service order on paper.
Mechanics previously received paper work orders.
The problem
Mechanics previously received paper work orders and executed their maintenance workflow from them. Estimate: 20 mechanics × 4 orders a day × 6 minutes to note, return and type each sheet = 8 hours a day, one person's whole day spent on paper alone (figures: assumption).
What Appfy did
The application allowed mechanics to consult warehouse-related information. Mechanics could enter maintenance observations using their voice.
The gain
The project aimed to modernize maintenance work orders, replacing a paper-based mechanic workflow with a mobile application.
Scene 1 of 8 · The company
Tractors, conveyors and boilers, as examples.
Tractors, conveyors and boilers are examples, not a verified exhaustive inventory of deployed assets.
Scene 2 of 8 · The problem
The service order came printed, on paper.
Mechanics previously received paper work orders and executed their maintenance workflow from them.
Scene 3 of 8 · The problem
Scene 4 of 8 · The goal
The aim was a mobile application.
The project aimed to modernize maintenance work orders, replacing a paper-based mechanic workflow with a mobile application.
Scene 5 of 8 · What Appfy did
The order on the phone: parts, notes and voice.
The application allowed mechanics to consult warehouse-related information. Mechanics could enter maintenance observations using their voice.
Scene 6 of 8 · What Appfy did
Scene 7 of 8 · What changed
The aim was a mobile application in place of paper.
The project aimed to modernize maintenance work orders, replacing a paper-based mechanic workflow with a mobile application. Mechanics could enter maintenance observations using their voice.
Scene 8 of 8 · And in your company?
Does your team still work on paper? Put the order on the phone.
If your team works away from the office, in the field or where the signal fails, Appfy puts the paper on the phone and connects every record to your system. Start with a free 30-minute conversation.
Global furniture retailer
Big companies don't buy by card.
Whoever picks the chair is not who approves it, and every purchase goes through the company's own system.
The problem
A global furniture retailer sells to companies through a portal with a tailored catalogue. But the client only approves purchases in its own system, and without a link someone types every cart again. Estimate: 1,000 orders a month × 15 minutes retyping each (assumptions) = 250 hours a month, more than one full-time employee.
What Appfy did
Appfy took part in connecting the catalogue and the portal to the company's purchasing process. In the documented design, the cart returns to the procurement system, the manager approves the request, and the purchase order is sent to the supplier after that approval.
The gain
In the documented design, the end user selects products in the supplier catalogue, the supplier returns that cart to procurement, and the manager approves the request. Procurement reconciles the purchase order, the receipt and the invoice. The invoice is matched with the purchase order and the receipt before payment processing.
Scene 1 of 8 · The company
A tailored catalogue for each company.
A global furniture retailer also sells to companies and governments, through a portal with a tailored catalogue for each client. But in a large company, whoever asks is not who approves.
Scene 2 of 8 · The problem
The cart was in one place; the rules, in another.
The catalogue sat on the retailer's portal; the buying rules, in the client's system, where the manager approves and the invoice is checked. Without a bridge, someone types it all again.
Scene 3 of 8 · The goal
Choose in the catalogue, approve in the company's own system.
The goal: connect the catalogue to each client's purchasing system, the management system large companies use. The employee goes in through it, chooses as in a shop and comes back with the cart.
Scene 4 of 8 · The choice
The main rule: a cart is not an order.
The cart that comes back from the catalogue is only a proposal. Once sent, it becomes a request and waits for the manager. Only after approval is the purchase order created; if the manager refuses, nothing is ordered.
Scene 5 of 8 · What Appfy did
From catalogue to invoice, an exchange of envelopes.
In the documented design, the supplier returns that cart to procurement, and procurement generates and sends the purchase order. Procurement reconciles the purchase order, the receipt and the invoice. The invoice is matched with the purchase order and the receipt before payment processing.
Scene 6 of 8 · What Appfy did
Changing the tyre while the car is moving.
Appfy took part in connecting the catalogue and the portal to the company's purchasing process.
Scene 7 of 8 · What changed
The manager approves where they always have.
In the documented design, the end user logs into procurement, the manager approves the request, and the purchase order is issued to the supplier after that approval.
Scene 8 of 8 · And in your company?
Selling to large companies? Get into their purchasing system.
If large companies or the government buy from you, a good catalogue is not enough: it has to talk to the client's purchasing system. Start with a free 30-minute conversation.
Large US bank
An offer can't wait 5 days for a ticket.
At a large bank, changing an offer took 3 to 5 days: everything went through a ticket.
The problem
In a large US bank's discounts and offers programme, every new offer or change became a ticket for support, with a 3-to-5-day turnaround, because only the technical team touched the data, directly in the database. Estimate: 200 offer changes a month × 4 days of waiting ≈ 27 offers always stuck in the queue, and 200 developer hours a month at 1 hour each (changes and hours: assumptions).
What Appfy did
Appfy built the console that put campaigns in the manager's own hands: they create and change offers and upload lists in batches, and the system applies them on its own. Behind it: the screens, the part that saves the data, the number summaries and the sign-in.
The gain
The work gave the manager the ability to run campaigns in batches. No measured result is verified.
Scene 1 of 7 · The company
Offers in front, a queue of tickets behind.
A large US bank runs a discounts and offers programme. Customers see the offers; behind them, every new offer or change became a ticket for support.
Scene 2 of 7 · The problem
Changing an offer took 3 to 5 days.
Discounts, coupons, merchants, lists, users. Every change became a ticket for support, because only the technical team touched the data, directly in the database, and each one waited 3 to 5 days.
Scene 3 of 7 · The goal
The goal: managers run their own campaigns.
Take the manager out of the queue. For that, a console with a sign-in and one area for each task: view and edit an offer, search customers and merchants, and a dashboard.
Scene 4 of 7 · What Appfy did
The front and the back of the console.
Appfy did both ends: in front, the manager's screens; behind, the part that fetches the offer and saves the change, with nobody touching the data directly.
Scene 5 of 7 · What Appfy did
Campaigns in batches, applied on their own.
The manager uploads a whole list at once, and the system applies it on its own, in batches. Automatic routines summarize the numbers for the dashboard, and one sign-in opens everything.
Scene 6 of 7 · What changed
No ticket: managers change their own campaigns.
The work gave the manager the ability to run campaigns in batches. No measured result is verified.
Scene 7 of 7 · And in your company?
Does changing an offer take days? Put control in the hands of whoever decides.
If every change to a price, offer or record becomes a ticket, Appfy builds the console so whoever decides can do it alone. Start with a free 30-minute conversation.
Large toll-tag company
Thousands of partners in one portal, each seeing only their own.
Fuel stations, car parks, drive-throughs and car washes: the owner, the finance person and the operator of each one come in through the same door.
The problem
The partners that accept a large toll-tag company's tag needed one portal, where each person signs in alone and sees only what is theirs. Estimate: 3,100 sites × 1 access request a month × 20 minutes of support ≈ 1,033 hours a month, about 5.9 people. The site total is a rounded Forbes Brasil count, not a portal user count. Requests, minutes and a 176-hour month are assumptions. This is not a measured saving.
What Appfy did
The specified access work keeps what each person sees, kept apart from what they can do. The proposed portal was to synchronize the CBILL registration and allow a synchronized partner to be enabled for operation.
The gain
Email and password are the documented entry. On first access the person changes the password and then reaches the profile-driven menu. Assignment to a group makes the person inherit that group's permissions. Gains were not measured.
Scene 1 of 8 · The company
Four businesses, one way in.
A large toll-tag company is also accepted at fuel stations, car parks, drive-throughs and car washes. These partners needed one portal to see the sales paid with the tag.
Scene 2 of 8 · The problem
Very different people through the same door.
Through the same door would come the company's staff and each partner's owner, finance person and operator. Each one could see only their own, like a key to their own room.
Scene 3 of 8 · The goal
First, get right who comes in and how.
The portal started with access: user groups, sign-in and password recovery. Partners already registered came into the portal, but only operate once enabled, like a badge that has to be activated.
Scene 4 of 8 · The choice
Seeing is one thing; being allowed to act is another.
Appfy split access into two parts: a map of the businesses a person sees and a profile of what they can do. Each group joins one map and one profile.
Scene 5 of 8 · What Appfy did
Nine paths, from sign-up to menu.
One example: the administrator puts a person in a group and they inherit the group's permissions. At first access, they change the password, pick the business and see only their own menu.
Scene 6 of 8 · What Appfy did
Two proposals, custom authorization or Cognito.
The two architecture figures dated 18 August 2020 are explicitly labeled Proposal 1 and Proposal 2. Proposal 1 names customAuthorizer. Proposal 2 introduces Cognito. No selected option is established. Final architecture remains unresolved. The annotation about validating permissions on each request does not prove that a Cognito post-authentication trigger handles every later API request.
Scene 7 of 8 · What changed
Each person signs in and sees only what is theirs.
Now a person is registered once, in a group, and signs in seeing only their own sites and their own menu. First access and password changes do not depend on anyone at the company.
Scene 8 of 8 · And in your company?
Many different people in one system? Start with access.
A portal for resellers, clients or partners? Appfy separates what each person sees from what each person can do first. Start with a free 30-minute conversation.
Hotel groups
In one QA operation, the API was interrupted for about 2 minutes. That observation is not time saved.
In a hotel restaurant, an update can leave everything switched on and still the order never reaches the kitchen.
The problem
In the restaurants of several hotel groups, every server was created one by one, with the settings repeated for each group, and a server switched on did not guarantee the order reached the kitchen. Estimate: 20 restaurants × 1 hour of dinner stopped × R$6k an hour (40 bills of R$150) ≈ R$120k for every update that stalls (figures: assumptions).
What Appfy did
Appfy built the path updates take from scratch: a written recipe sets up every server, in each hotel group's own setup, always in the same steps, and the last step checks that the order goes from table to kitchen. The team got the manuals.
The gain
Every new version follows the same steps, and replacing a server means setting up another from the recipe.
Scene 1 of 8 · The company
From table to kitchen, the order has to arrive right.
Hotel groups run a till and kitchen system in their restaurants: the waiter enters the order, the kitchen sees it on screen, the bill is split and the receipt prints.
Scene 2 of 8 · The problem
A light on did not mean the order was getting through.
Every server was created one by one, like cooking every dish from memory, and the settings were repeated for each hotel group. A server switched on did not guarantee the order reached the kitchen.
Scene 3 of 8 · The goal
Done is when the order goes through, not when the server switches on.
Appfy took on the path that brings every new version to the servers. The goal: the same steps every time, like a conveyor belt, and done only when an order makes the whole trip.
Scene 4 of 8 · The choice
Instead of fixing each server, set up a new one from the recipe.
Appfy wrote a recipe for each type of server. Every new version gets a new recipe: new servers are made from it and take the place of the old ones, which are switched off.
Scene 5 of 8 · What Appfy did
Every new server sets itself up when it starts.
When it starts, the new server follows a script: it fetches the instructions, installs the versions and starts the system. The database got a step of its own, and the team got the manuals.
Scene 6 of 8 · What Appfy did
Four healthy replacements/PM2 processes. Only two of four refreshes complete at the snapshot.
In one QA operation, the API was interrupted for about 2 minutes. That observation is not time saved. Four healthy replacements/PM2 processes. Only two of four refreshes complete at the snapshot. Later, the RCA handoff said the application still used the previous database.
Scene 7 of 8 · What changed
Every update ends with one question: did the order arrive?
Now every version follows the same steps, replacing a server means setting up another from the recipe, the team has a manual in hand and the last question is always the same: did the order arrive?
Scene 8 of 8 · And in your company?
Updating systems while you are open? First define what done means.
If the operation cannot stop, Appfy writes every step, checks them one by one and finishes on the customer's path, not on the light being on. Start with a free 30-minute conversation.
Ticketing platform
Move the back office without closing the box office.
A ticketing platform needed room to grow without taking down the site where the public buys.
The problem
The site the public sees and the back office, with accounts, payments and emails, ran together and needed to grow. Estimate: 1 hour stalled when a show goes on sale × 2,000 tickets an hour × R$200 (assumptions) ≈ R$400k in stalled sales.
What Appfy did
Appfy moved only the back office to the cloud, left the site where it was and put a door with a doorman between them, which also holds back floods of requests. Payments and emails went into queues that retry and alert the team when something fails.
The gain
For buyers, the site is the same. The records show a separate DLQ, alert and retrigger path. No ticket correctness or successful email delivery is established, and there is no configured retry policy or tested recovery.
Scene 1 of 7 · The company
Storefront and back office in one building.
A platform sells tickets for shows and events. The site the public sees and the back office, with accounts, payments and emails, ran together, like a shop and its stockroom in one building.
Scene 2 of 7 · The problem
Growing without going down, and without letting bots in.
The platform had to handle more people at once, stay online and block floods of requests and bots. With everything in one building, growing one part meant growing it all.
Scene 3 of 7 · The choice
Only the back office moves building.
Appfy moved only the back office to the cloud: accounts, payments, events and emails. The site stayed where it was, and between the two a door with a doorman checks the key of every message.
Scene 4 of 7 · What Appfy did
An email that fails does not vanish: it alerts the team.
Whoever buys a ticket gets an email. Now that message joins a queue, like a ticket number at a counter, and goes out in turn. If it fails, it retries; if it keeps failing, it alerts the team.
Scene 5 of 7 · What Appfy did
What the records show for the accounts is an initial sketch. It proposes completing the Google, Okta and Facebook setup, and audit records for login, logout, signup and modify. Its premises include not storing passwords. Those statements are the proposal's semantics, not verified behavior.
Scene 6 of 7 · What changed
On screen, nothing changes.
Buyers stay on the same site. The records show a separate DLQ, alert and retrigger path. No ticket correctness or successful email delivery is established, and there is no configured retry policy or tested recovery.
Scene 7 of 7 · And in your company?
Has your platform outgrown itself? Move only what needs to move.
Changing systems does not have to be all or nothing. Appfy first draws what stays and what moves, and how the two parts talk. Start with a free 30-minute conversation.