The website needed more than a new design
Osfin automates some of the least forgiving workflows inside financial operations: reconciliation, payments, settlements, exceptions, and the data moving between banks, gateways, ERPs, and internal systems. The company had already built a serious enterprise product around those problems. As it prepared to expand more aggressively into Western markets, the digital presence around that product had to change.
Osfin was selling into several industries, to different kinds of financial and operational teams, each arriving with a different problem. A bank was not looking for the same thing as an insurer. A payments company did not describe its problem the same way as a retailer. A fintech might arrive looking for one specific reconciliation workflow without knowing Osfin existed. The existing website did not have enough surface area to meet those buyers where they were, so we started with architecture rather than a new homepage. The site is live at osfin.ai.
The website became a distribution problem
Our first question was not what the new homepage should look like. It was how many meaningful ways the right company could discover Osfin. That changed the project immediately. Instead of treating the website as a handful of corporate pages, we started mapping the market: industries, use cases, problems, products, search behavior, customer stories, and the questions buyers were already asking.
The objective was to create enough relevant surfaces that each important ICP could enter through a page that actually spoke its language — not one generic landing page trying to explain everything to everyone.
One platform. Many entry points.
Osfin’s platform could serve very different financial environments, including banking, payments and cards, fintech, insurance, capital markets, gaming, and retail. The problems inside those industries are not interchangeable. A bank might be reconciling enormous volumes across cards, accounts, or ATM networks. A fintech might be dealing with disbursements, repayments, and payment gateways. An insurer has another set of financial workflows. A retailer might be reconciling transactions, settlements, inventory, and multiple payment channels.
So we began creating industry-specific and use-case-specific surfaces around the platform. Each could be discovered independently, speak more specifically, rank for a different set of problems, and still lead back into the larger Osfin platform. The idea was to give every important ICP a door into Osfin.
More surface without fragmenting the brand
The danger with this strategy is obvious: you can create hundreds of landing pages and accidentally turn a coherent company into an SEO directory. Every industry needed specificity, but every page still needed to feel unmistakably Osfin. Architecture, brand, and components had to work together so new pages were not designed as independent artifacts.
Once that was clearer, we rebuilt the surface layer: visual language, hierarchy, content architecture, and reusable patterns. The objective was not a cosmetic rebrand. We needed a system that could support industry pages, solution pages, product explanations, case studies, customer proof, blogs, technical information, conversion points, and whatever Osfin needed to publish next. We brought the broader experience onto Webflow because if distribution depended on creating more useful surfaces, marketing could not wait for an engineering release every time it needed another one. The website had to become something Osfin could continuously operate.
A publishing system search could live in
Content was part of the Western-market expansion. Osfin was not in a category where every buyer already understood the terminology, the problem, or the available solutions. Someone researching a broad question around reconciliation could discover Osfin early. Someone searching for a specific workflow could arrive much closer to purchase intent. Someone evaluating the company after a referral could find deeper material proving the team understood their problem. The blog could not remain an afterthought.
We turned it into a scalable editorial system: reusable article structures, stronger reading hierarchy, table-of-contents behavior, featured imagery, thumbnails, configurable metadata, contextual CTAs, internal linking, responsive reading, and CMS structures that could support continued publishing. We were not designing ten articles. We were designing the system that could eventually hold hundreds.
Osfin was also working with an external SEO partner, which meant we were not operating inside a design bubble. Search requirements affected architecture, architecture affected design, design affected performance, and performance affected search. We worked alongside Osfin and its SEO partners on landing-page architecture, metadata, schema, internal linking, redirects, CMS structure, technical SEO, templates, content presentation, calls to action, image optimization, and performance. The system had to accommodate both.
The product had enough proof
We did not need to manufacture credibility. The product was already being used for serious financial operations. Osfin publicly describes integrations across more than 170 data sources and systems, with the platform processing large financial datasets across several industries. Published customer stories include PharmEasy, Games24x7, ManipalCigna Health Insurance, and BukuWarung. The company has also published reconciliation outcomes including high levels of automation and accuracy, reductions in manual processing time, and significant operational savings.
Those are Osfin’s product outcomes, not outcomes of our website work. That distinction matters. When a company already has evidence, the website does not need to compensate with louder marketing. It needs to make that evidence easy to discover, understand, and trust.
Then the site started growing
As the architecture expanded, more content shipped, blogs began driving traffic, and industry and solution surfaces increased, we ran into a different problem from the one we started with: the website was becoming expensive to serve. The existing Webflow CMS plan included 50 GB of monthly bandwidth. Usage rose from 68 GB in May 2025 to 144.7 GB in December and 135 GB in January 2026 — almost three times the allowance at its peak. That was a problem created by a website that was being used differently.
The obvious response would have been to upgrade the plan. We did not start there. Before optimization, the site was consuming about 4.6–5 GB of bandwidth a day, much of it from large, under-compressed images on high-traffic blog pages. We compressed and re-uploaded the major assets first. In the first two days of February after that work, the site consumed about 5.7 GB total, or roughly 2–3.6 GB a day. We did not want less traffic. We wanted less infrastructure waste per visitor.
Optimization did not change the larger trajectory. Busy months were already at 135–145 GB, traffic was growing, and the CMS was going to keep expanding. After reducing the waste, we recommended Webflow’s Business Site plan and higher CMS capacity so useful growth had room to continue. The order mattered: do not scale inefficient infrastructure. Optimize it first.
The relationship kept expanding
What started as a Western-market website engagement crossed into other parts of Osfin’s digital operation as the company changed. That included compliance work around CCPA, cookie consent, privacy-policy updates, and tracking behavior — unglamorous, but not optional for an enterprise financial-operations company, and not independent of the rest of the stack. Cookie consent affects analytics, analytics affects marketing, scripts affect performance, and performance affects search. The website sits in the middle.
As the system matured, Osfin also added more intelligence around visitors and conversion, including ZoomInfo’s WebSights, Chat, FormComplete, and Schedule. The site was no longer only visit, read, form. It became part of a larger acquisition path: discovery, a relevant landing surface, content, intent, visitor intelligence, conversion, and sales. We did that work alongside Osfin’s stakeholders and their external SEO team. SEO recommendations had design consequences, Webflow decisions affected performance, and marketing tooling introduced scripts. Coordination was part of the job, not a side effect of it.
We did not create Osfin’s reconciliation technology, produce its customers’ financial outcomes, or claim the website created the company’s growth. We built and kept operating the digital surface through which more of the market could discover what Osfin had already built. First we helped create more distribution. Then we helped make that distribution cheaper to operate. That is the more interesting definition of a website: not something you launch, but something that compounds.
