See what Global Technology Solutions has built, and how other organizations used the same kinds of technology. Every public case links to its source and ends with how we would approach a similar project.
37 case studies: 7 built by GTS, 27 industry case studies and 3 client projects. Built by GTS means our own products and tools. An industry case study is a project by another organization, shown with its source. We were not involved in those.
gtsltd.in: our own website, pre-rendered and built from data
You are on it now. We designed and built this site ourselves with React and Vite. Every page is pre-rendered to static HTML, so it opens quickly and can be read by search engines.
125
Location and guide pages built from data
45
Blog posts from one index
10
Service pages from one data file
2560 px
Widest screen tested. The narrowest was 320 px
The Need
A company site needs many pages for services, regions and guides, and each page needs its own title, description and links. Writing them by hand does not scale.
What GTS Built
One React codebase where service, location, guide, blog and Zavik pages come from data files. The build writes the sitemap and pre-renders every page. The stylesheet is inlined, and the Poppins font files are served from the site itself.
What You Can See
Each location and guide page has its own title, description and FAQ markup. Job pages read from a database when it is connected. We checked the site at screen widths from 320 to 2560 pixels and fixed anything that was cut off on phones, tablets or large monitors.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
We built a small page system that turns structured data into complete pages, so a new region or guide is a data entry and not a new template.
125
Pages generated from data
12
Page groups, from regions and countries to guides
3
Interactive tools a page can embed
1
Template for every page
The Need
Buyers search for a service in a place or on a topic. Each search needs a page that answers it honestly, with its own details, questions and next step.
What GTS Built
Each page is a data entry with an intro, sections, FAQs and a call to action. One page component renders them all, adds FAQ and breadcrumb markup, and can embed a calculator or a live demo after a chosen section.
What You Can See
The 12 groups cover regions, countries, Google Workspace, blockchain, India and guides. Every group follows the same rules, and the sitemap picks new pages up automatically.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
Twitter Lite: a mobile web app built for slow networks
Twitter rebuilt its mobile website as a progressive web app. It became the default mobile web experience for all users worldwide in April 2017.
65%
More pages viewed per session
75%
More tweets sent
20%
Lower bounce rate
600 KB
App size over the network, against 23.5 MB for the Android app
The Situation
Twitter wanted its mobile website to load faster, keep people engaged and use less data.
What They Did
It built a progressive web app. Service workers cache views and assets, the first HTML is streamed, and only what the visible screen needs is loaded. Media is smaller by default, and a data saver mode lets people choose when media downloads. It also added an install prompt and web push notifications.
The Reported Result
First load over 3G takes under 5 seconds on most devices, and repeat loads under 3 seconds. Average load time for logged-in users fell 30%, and data use while scrolling timelines fell by as much as 70%. Each day about 250,000 people open it from their home screen.
We would set a size budget for the first load, send server-rendered HTML with JavaScript split by route, and add a service worker for repeat visits. We would test on a real mid-range phone over a throttled connection before launch, not only on a fast laptop.
Pinterest: rebuilding mobile web as a progressive web app
Pinterest rebuilt its mobile website as a progressive web app after finding that its old mobile web converted only about 1% of visitors.
40%
More time spent
44%
More user-generated ad revenue
60%
More core engagements
5.6 s
Time to interactive on a first visit, down from 23 s
The Situation
Pinterest's old mobile web experience was slow, and only about 1% of unauthenticated mobile web visitors signed up, logged in or installed the app.
What They Did
The team rebuilt the mobile site as a progressive web app and cut the core JavaScript bundle from 650 KB to 150 KB.
The Reported Result
Time spent rose 40%, user-generated ad revenue rose 44% and core engagements rose 60%. On an average Android phone over slow 3G, time to interactive fell from 23 seconds to 5.6 seconds on a first visit, and to 3.9 seconds on repeat visits.
We would test the current site on a mid-range Android phone over a slow connection. Then we would set a JavaScript budget for the first screen and split the code so each route loads only what it needs. The goal is to win back visitors who leave before the page is usable.
Flipkart Lite: a progressive web app for shoppers on slow connections
India's largest e-commerce site had closed its mobile website during an app-only push in 2015. It then built Flipkart Lite, a progressive web app that mixes the reach of the web with app-like speed.
3.5 min
Time per visit, up from 70 seconds
40%
Higher re-engagement
70%
Higher conversion for visitors who open the home screen icon
3x
Less data than the native app for a first purchase
The Situation
Flipkart shut its mobile website in 2015 as part of an app-only strategy. It then wanted a mobile experience that combined the reach of the web with the speed and re-engagement of a native app.
What They Did
Flipkart Lite loads fast, browses offline and adds a home screen icon so shoppers can come back in one tap.
The Reported Result
Visits lasted about 3.5 minutes, up from 70 seconds on the previous mobile experience. Re-engagement rose 40%. Of Flipkart Lite users, 63% arrived on 2G networks, and 60% of visits started from the home screen icon.
We would design for the slowest network your customers use: lean pages, cached product lists, an offline fallback and a well-timed install prompt. We would judge success by load time on 2G and 3G profiles as well as by sales.
AliExpress: one progressive web app for every mobile browser
AliExpress built a cross-browser progressive web app for its mobile site, to give web visitors app-like speed, offline use and re-engagement without an install.
104%
Higher conversion for new users across all browsers
82%
Higher conversion on iOS Safari
2x
Pages viewed per session
74%
Longer average session
The Situation
AliExpress wanted mobile web visitors to get the speed, offline support and re-engagement of an app, without having to install one.
What They Did
It built a single progressive web app that works across browsers, including Safari on iPhone.
The Reported Result
Conversion for new users rose 104% across all browsers and 82% on iOS Safari. Visitors viewed twice as many pages per session, and sessions lasted 74% longer on average.
We would build the mobile site as one codebase that works in every common browser. We would add offline support and home screen install where the browser allows it. We would test on iPhone Safari as well as Chrome, because install and push features differ between them.
Rakuten 24: an installable web app instead of two native apps
Rakuten 24, an online store run by Rakuten, made its web app installable as the first step of a gradual progressive web app rollout. This avoided the cost of separate iOS and Android apps.
310%
More visits per user than other web users
450%
Higher visitor retention than the previous mobile web flow
150%
Higher sales per customer
The Situation
The team wanted app-like engagement from its web app without building and maintaining separate iOS and Android apps.
What They Did
It added a custom install prompt using the beforeinstallprompt event, plus a manual install guide for people who missed the banner. Service workers built with Workbox cache CSS and JavaScript first, and refresh rarely changing images in the background.
The Reported Result
Over one month, people who installed the app visited 310% more often than other web users and had 150% higher sales per customer. Retention was 450% higher than in the previous mobile web flow. These figures compare people who installed the app with people who did not, so they do not prove that the install itself caused the gain.
We would start with the smallest useful step: make the site installable, cache the app shell and add a clear install prompt. We would measure installs and repeat visits first, then add features such as push notifications only where they help.
Tinder: a progressive web app tuned one change at a time
Tinder built a progressive web app and documented how each change made it faster, from code splitting to performance budgets.
5.9 s
To load and become interactive on a Galaxy S7 over 4G
101 KB
Main bundle after route-based splitting, down from 166 KB
1 s
About one second saved by preloading critical bundles
10%
Of the native app data cost for the core experience (about 2.8 MB)
The Situation
Tinder wanted a web app that loads quickly and stays affordable for people in markets where mobile data is costly.
What They Did
The team split code by route and preloaded critical bundles. It switched to Atomic CSS and set size limits for each bundle. A Workbox service worker caches the app shell for repeat visits.
The Reported Result
Route-based splitting cut the main bundle from 166 KB to 101 KB and DOMContentLoaded from 5.46 to 4.69 seconds. Preloading saved about a second. Atomic CSS lowered the average page load from about 6.75 to about 5.75 seconds. The write-up does not include business metrics.
We would give every page a size budget and fail the build when it is exceeded, so the site cannot quietly grow heavier. Route-based splitting, preloading and a cached app shell are the first things we would try.
Vodafone: a 50/50 test that tied page speed to sales
Vodafone, a telecom operator in 21 countries, compared a speed-optimized landing page with the original page in a live A/B test.
31%
Faster Largest Contentful Paint (5.7 s against 8.3 s)
8%
More total sales
15%
Better lead-to-visit rate
11%
Better cart-to-visit rate
The Situation
Vodafone wanted to know whether faster pages really sell more. It split paid traffic 50/50 between an optimized page and the baseline. Both had the same design and features, and each got about 100,000 clicks a day.
What They Did
The team moved the rendering of a widget from the browser to the server and rendered the critical HTML there. It also optimized images: it resized the hero image, cleaned up SVGs and PNGs, and delayed images outside the viewport.
The Reported Result
Measured on real user sessions, Largest Contentful Paint improved by 31%. Total sales rose 8%, the lead-to-visit rate rose 15% and the cart-to-visit rate rose 11%.
We would measure real-user speed first and fix the biggest causes, such as render-blocking JavaScript and heavy images. Then we would run the old and new page side by side before rollout, so the effect on sales is measured and not assumed.
The UK Government Digital Service launched GOV.UK on 17 October 2012. It replaced the Directgov and Business Link websites, which closed on the same day.
2
Older government sites replaced on launch day
£70M
Expected yearly saving at launch (up to)
24
Departments planned to move by March 2013
Open
Source software, avoiding license costs
The Situation
The government wanted one simpler site for public services, built around what people need to get done, instead of separate sites such as Directgov and Business Link.
What They Did
The Government Digital Service rewrote and redesigned the content instead of copying it. The site runs on open source software, was tested in public so real-user feedback could guide changes, and was planned to take in 24 departments by March 2013.
The Reported Result
The two old sites closed on launch day. At launch the government expected the new approach to cost taxpayers up to £70 million a year less than the services it replaced. That is a projection, and the release gives no figure for savings actually achieved.
For a large content site we would start from user tasks, merge overlapping pages and set one design system with clear editing rules. We would move sections in stages and watch usage after each stage.
Custom Software
Applications, platforms and the architecture choices behind them.
Zavik: HR, sales, finance and operations in one business platform
Zavik is our own software product. We designed, built and support it. It puts 14 modules behind one login, priced per user in rupees.
14
Modules under one login
3
Plans, priced per user in rupees
5 days
Free trial with every module, no card needed
CSV
Bulk import of your employee list
The Need
Growing teams often use one tool for attendance, another for sales and a spreadsheet for stock, so the same customer or employee gets typed into several places.
What GTS Built
We built one multi-tenant platform where HR and payroll, sales and CRM, finance, inventory, procurement, projects and eight more modules share the same records. Each company's data is kept separate from every other company's, files are stored privately and opened through short-lived links, and billing runs through Razorpay.
What You Can See
The 5-day trial opens all 14 modules without a card. Payroll is worked out from base salary and attendance, and payslips are created and paid through RazorpayX. Zavik does not calculate PF, ESI or TDS, and we say so up front.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
A careers site with job posting, applications and an admin page
We built our own hiring portal. Open roles show on the careers page, candidates apply with a resume, and our team manages roles and applications from a protected admin page.
4
Application statuses: new, selected, rejected and hired
3
Resume formats accepted: PDF, DOC and DOCX
1
Admin page for posting and managing roles
Auto
Closed roles drop out of the sitemap on the next build
The Need
Hiring through a shared inbox loses applications and makes it hard to see who is at which stage.
What GTS Built
Jobs live in a database and only active roles are shown. The application form uploads the resume to storage and saves the application. A sign-in protected admin page lets our team manage roles, open each resume through a short-lived link and move applications through the hiring statuses.
What You Can See
The careers pages fall back to a built-in list if the database cannot be reached, so visitors never see an empty error page. Job pages and the sitemap list active roles only.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
Calculators that give a rough answer before you call
We built three small calculators for this site: a project timeline estimator, a security risk score and a Google Workspace price calculator.
3
Calculators built into the site
24
Timeline combinations the estimator can show
5
Questions behind the security risk score
18%
GST added automatically in the price calculator
The Need
Most visitors want a rough idea of time, risk or cost before they are ready to talk to anyone.
What GTS Built
Each calculator runs in the browser with simple rules. The estimator combines a service track, a project size and a delivery speed into a timeline and a suggested team. The risk score adds up five answers about infrastructure, audits, data and access. The price calculator multiplies users by a fixed rate and adds GST.
What You Can See
The price calculator states that your written quote is the final price. The risk score is a simple scoring guide and not a security audit.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
Shopify: keeping one codebase and adding clear boundaries
Shopify has one of the largest Ruby on Rails codebases in the world. Instead of splitting it into many services, it reorganized it into components with clear boundaries.
6,000
Ruby classes moved in one automated change
1,000+
Developers who worked on the codebase over a decade
1
Repository and deployment unit
2017
Year the componentization effort began
The Situation
By 2016 the single codebase caused problems. Changing tax calculations could alter shipping rates, tests were slow, and new developers had to learn many unrelated areas before making simple changes.
What They Did
Starting in early 2017, Shopify reorganized code around real-world concepts such as orders and shipping instead of technical roles. Each component has a public API and owns its data, and an in-house tool called Wedge flags calls that cross component boundaries.
The Reported Result
The team could replace a legacy tax engine with a new system, which would have been nearly impossible before the decoupling. Shopify chose a modular monolith to gain modularity without running many separately deployed services.
For custom software we would build one deployable application split into modules, each with its own data and a small public interface. This keeps hosting simple, and a module can become its own service later if it needs to scale on its own.
Segment merged more than 140 services into one service and one repository to make its destinations pipeline easier to change and test.
140+
Services merged into one
<1 s
Test runs for 140+ destinations, down from up to an hour
46
Shared library improvements in the year after, against 32 before
120
Dependencies moved to a single version
The Situation
Segment sent events to over 100 types of destinations, each with its own service and repository. Shared libraries drifted apart, tests were slow, and at one point three full-time engineers spent most of their time keeping the system running.
What They Did
The team merged the services into one and moved all destination code into one repository. It put about 120 dependencies on a single version. It also built a tool that records HTTP traffic and replays it, so tests no longer depend on live endpoints.
The Reported Result
Test runs dropped from up to an hour to milliseconds, and one engineer could deploy the service in minutes. Shared library improvements rose from 32 in the microservice period to 46 in the year after. Segment also named the trade-offs: a crash can affect every destination, and upgrading a shared dependency can break several at once.
We would start a new product as one well-organized codebase and split a service out only for a clear reason, such as different scaling needs or a separate team. Going back is possible but costly, so we would decide early and write the reasons down.
Prime Video: a monitoring service rebuilt as one process
Prime Video's team rebuilt one of its video quality monitoring services as a single process, after its first serverless design hit scaling and cost limits.
90%+
Lower infrastructure cost
5%
Of the expected load: where the first design hit its limit
1
Process holds all components in the new design
Memory
Replaces S3 for passing video frames between steps
The Situation
The first version used AWS Step Functions and Lambda, with S3 storing video frames between steps. It was quick to build, but it hit a hard scaling limit at about 5% of the expected load and cost too much at large scale.
What They Did
The team packed all components into one process and passed data through memory instead of S3. The result runs as one long-lived service that scales out on Amazon ECS.
The Reported Result
Infrastructure cost fell by more than 90%, and the service could scale further. Commentators pointed out that this was one service, not a move away from microservices across all of Prime Video.
We would choose the architecture from the workload, not from fashion. For a job that passes large data between many small steps, we would test a single-process design early. We would compare its cost with the distributed one before building either at scale.
Discord: moving trillions of messages to a faster database
Discord moved its message storage from Cassandra to ScyllaDB as the number of stored messages grew from billions to trillions.
177 to 72
Database nodes after the move
15 ms
p99 time to fetch old messages, down from 40 to 125 ms
5 ms
p99 time to save a message, down from 5 to 70 ms
9 TB
Disk per node, against an average of 4 TB before
The Situation
In 2017 Discord stored billions of messages on 12 Cassandra nodes. By early 2022 it stored trillions on 177 nodes. Latency was hard to predict, hot partitions could slow a whole cluster, and maintenance had become costly.
What They Did
It moved the message store to ScyllaDB. The new cluster needed 72 nodes with 9 TB of disk each, compared with an average of 4 TB per Cassandra node.
The Reported Result
The p99 time (the slowest 1% of requests) to fetch historical messages fell from 40 to 125 milliseconds to about 15 milliseconds. The p99 time to insert a message fell from 5 to 70 milliseconds to a steady 5 milliseconds. The cluster shrank from 177 nodes to 72.
We would model the access patterns first, load-test the database with realistic data volumes, and watch the slowest 1% of requests, not only the average. If a database starts to need constant care, we would plan the move early and run old and new side by side.
Cloudflare: replacing NGINX with a proxy written in Rust
Cloudflare built Pingora, a proxy written in Rust, to replace NGINX in the service that connects Cloudflare to the internet.
70%
Less CPU for the same traffic
67%
Less memory for the same traffic
1T+
Requests handled per day
99.92%
Connection reuse for one major customer, up from 87.1%
The Situation
NGINX's process-per-worker design spread load unevenly across CPU cores and limited connection reuse, because each worker kept its own pool. Some features, such as retrying a request on a different origin with different headers, were hard to add. The team also wanted to move away from C and Lua.
What They Did
Cloudflare wrote Pingora in Rust, a memory-safe language, as a new proxy that now handles over 1 trillion requests a day.
The Reported Result
With the same traffic, Pingora uses about 70% less CPU and 67% less memory. For one major customer, connection reuse rose from 87.1% to 99.92%. Median time to first byte dropped by 5 milliseconds, and the 95th percentile by 80 milliseconds.
A rewrite like this only makes sense at huge scale. For most clients we would profile the slow path, fix the biggest cost first, and rewrite a component only when measurements show that tuning cannot reach the target.
UPI: a national payment system running at 172 billion payments a year
The National Payments Corporation of India (NPCI) launched UPI in 2016. It is a real-time payment system that moves money between bank accounts, and one app can hold several accounts.
172B
UPI transactions in 2024, up from 118B in 2023
₹247T
Value in 2024 (₹247 lakh crore), up from ₹183 lakh crore
16.73B
Transactions in December 2024 alone
2016
Year NPCI launched UPI
The Situation
UPI was designed to make payments between bank accounts instant and interoperable, so people are not tied to one bank or one app.
What They Did
Users link bank accounts to a UPI-enabled app and pay with a UPI ID. The payment request goes through the app's payment service provider to NPCI for verification. Payments can be pushed by the payer or pulled by the payee.
The Reported Result
NPCI data reported by IANS shows about 172 billion UPI transactions in 2024, up roughly 46% from about 118 billion in 2023. Their value was nearly ₹247 lakh crore, up about 35% from ₹183 lakh crore. December 2024 alone had about 16.73 billion transactions worth about ₹23.25 lakh crore.
For payment features we integrate with an established gateway such as Razorpay. We would design for retries and duplicate callbacks and reconcile every payment against the gateway's record. We would test failure cases before launch, because a payment must never be charged twice or go missing.
Dropbox: moving most data from AWS to its own infrastructure
Dropbox moved most of its data from AWS to infrastructure it runs in colocation data centers. Its 2018 IPO filing reports the savings.
$74.6M
Lower operating costs over about two years
$92.5M
Drop in the AWS bill in 2016
$39.5M
Net infrastructure saving in 2016, after new costs
10%
Of its data still kept on AWS
The Situation
Dropbox stored most of its data on AWS. Storage is the core of its product, so the rented infrastructure was a major cost.
What They Did
Dropbox ran a project it called Infrastructure Optimization. It moved most data to its own systems in colocation facilities and kept some on AWS, mainly to stay close to users in Europe and parts of the US.
The Reported Result
The filing reports $74.6 million in lower operating costs over about two years. In 2016 the AWS bill fell by $92.5 million, and after added costs such as colocation and staffing the net infrastructure saving was $39.5 million. In 2017 infrastructure costs fell by a further $35.1 million. The figure also includes a project that deleted data from long-inactive users.
Few companies are as large as Dropbox, so the math differs for most. We would compare hosting options using your real usage, move only the parts where the numbers clearly favor it, and keep a tested way back.
The company behind Basecamp and HEY moved its apps off the cloud and onto servers it owns.
$3.2M
Yearly cloud bill before the move
$700K
Server hardware, paid back by the second half of 2023
$2M
Yearly saving so far, about
$10M+
Expected saving over five years (company estimate)
The Situation
The company was paying about $3.2 million a year for cloud services.
What They Did
It bought about $700,000 of Dell servers and ran its own compute. For storage it planned a Pure Storage setup in two data centers, with 18 petabytes of combined capacity, to replace roughly 10 petabytes in AWS S3.
The Reported Result
The cloud bill fell to about $1.3 million a year, a saving of almost $2 million a year. The hardware paid for itself in the second half of 2023. The company expects savings of well over $10 million across five years. These are the company's own estimates, from a post by David Heinemeier Hansson of 37signals.
We would first measure what your current setup really costs and what each service needs. Many teams save more by right-sizing and removing unused services than by moving. If a move is right, we would plan it in stages with backups and a tested way back.
Blockchain
Shared records, smart contracts and tokens in real use.
We built a small working blockchain that you can edit. It shows why changing one record breaks every block after it.
SHA-256
Hash used for every block
000
Prefix each hash must start with (proof of work)
3
Blocks mined when the page opens
None
Data sent to a server. It all runs on your device
The Need
People hear that a blockchain cannot be changed quietly, but it is hard to see why until you try to change one.
What GTS Built
Each block holds some data, the hash of the block before it and its own hash. The browser computes SHA-256 hashes and mines each block by searching for a nonce that makes the hash start with three zeros. Editing any block marks it, and every block after it, as broken.
What You Can See
Edit a block and watch the checks turn red. Press re-mine to repair the chain and see that every hash changes. Once the chain is valid you can add a block of your own. It is a teaching demo and not a real network.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
The rules of an escrow contract, simulated in your browser
We built an escrow simulation that follows the rules a smart contract would enforce. Try it as a buyer, a seller or a stranger.
3
Roles to act as: buyer, seller or stranger
4
Actions: deposit, deliver, release and refund
5
Contract states, including refunded
₹50,000
Sample amount held in escrow
The Need
Smart contracts are easier to trust when you can see the rules working, including what they refuse to do.
What GTS Built
A buyer deposits the money, the seller marks the work as delivered, and the buyer releases the payment, or cancels for a refund before delivery. Each step is only allowed for the right person and in the right order.
What You Can See
Try releasing the payment as a stranger, or before delivery, and the contract rejects it and says why. It is a simulation written in JavaScript. A deployed contract enforces the same rules on a blockchain.
Our own work
We built and run this ourselves, so you can open it and judge it for yourself.
Walmart and IBM Food Trust: tracing food to its source in seconds
Walmart used IBM Food Trust, a blockchain built on Hyperledger Fabric, to trace the source of food in seconds instead of days. In 2018 it told leafy green suppliers to join.
2.2 s
To trace a food item to its source, down from about 7 days
1 year+
Walmart and IBM worked together before a wider rollout
Sept 2019
Deadline for leafy green suppliers to upload data
Fabric
Hyperledger Fabric, running on IBM Cloud
The Situation
Tracing a food item back to its source took about 7 days. In 2018, after the romaine lettuce E. coli outbreak, Walmart announced a new requirement for its suppliers.
What They Did
Walmart worked with IBM for over a year on IBM Food Trust, which runs on IBM Cloud using Hyperledger Fabric. Suppliers of leafy greens for Walmart and Sam's Club had to upload their data to the blockchain by September 2019 and meet a Global Food Safety Initiative standard. Suppliers only needed to upload data, and IBM provided onboarding.
The Reported Result
Walmart reported that tracing the source of a food item dropped from about 7 days to 2.2 seconds.
A shared record helps when several companies must trust the same data. We would first map who writes the data and who reads it, then decide between a private blockchain and a normal database. We would also keep the supplier side simple, so companies without blockchain skills can join by uploading data, as Walmart did.
De Beers Tracr: recording where a diamond comes from
De Beers built Tracr, a blockchain platform that records where natural diamonds come from, starting at the point of recovery.
5M+
Rough diamonds registered
2/3
Of De Beers rough production by value is registered
2018
Year development began
2023
Year the platform opened to the wider industry
The Situation
Customers and the industry want to know where a natural diamond comes from. Tracr records this from the moment a rough diamond is recovered.
What They Did
De Beers began developing Tracr in 2018 and registers natural rough diamonds at source. In 2023 it opened the platform to the wider industry for rough-to-polish provenance checks. Since January 2025, all newly sourced De Beers rough diamonds of one carat and above are registered.
The Reported Result
More than five million rough diamonds are registered, about two thirds of De Beers rough production by value. Under a 2023 initiative, GIA includes Tracr provenance information on eligible diamond grading reports.
For a provenance system we would define the record at each hand-over: who, what, when and which document proves it. The blockchain would hold proofs and links, while the heavy documents stay in storage you control. We would also plan how new partners get onboarded.
TradeLens: a working platform that never reached enough of the industry
Maersk and IBM built TradeLens, a shared shipping platform, and announced in 2022 that they would close it. It is a useful lesson in adoption.
300+
Members on the platform
Nov 2022
Closure announced by Maersk
Q1 2023
Target date to take it offline
The Situation
Maersk and IBM wanted one shared platform for information exchange across the shipping industry.
What They Did
They built a working platform and signed up more than 300 members.
The Reported Result
On 29 November 2022 Maersk said the platform had not become commercially sustainable as a standalone business. It would go offline by the end of the first quarter of 2023. Maersk's head of business platforms said the company had built a viable platform but had not secured the full, global industry collaboration it needed.
Before building a shared platform we would ask who must join for it to be useful and what each member gains on day one. We would start with a small group that already shares a problem, prove the value there, and widen it later. We would also tell you if a shared database or a simpler tool is enough.
Dubai Land Department: real estate contracts on a blockchain
In 2017 the Dubai Land Department said it would record real estate contracts, including lease registrations, on a blockchain, as part of the Dubai Blockchain Strategy.
2017
Announced for GITEX Technology Week
2020
Dubai Blockchain Strategy goal: government transactions on a blockchain
3
Linked systems: DEWA, telecoms and property bills
Minutes
Stated time for the whole process
The Situation
The department wanted tenants to register leases and pay without cheques, printed paperwork or visits to a government office.
What They Did
With Smart Dubai and other partners, it built a secure database for real estate contracts. The system links to the Dubai Electricity and Water Authority, the telecoms system and property-related bills, and tenants can pay electronically.
The Reported Result
The department said the whole process would take a few minutes and could be completed online from anywhere. It did not publish numbers for time or money saved, and the claim to be the first government entity to adopt blockchain is its own.
Project by Dubai Land Department. Facts from Gulf News .
How GTS would build it
For a registry like this we would agree the rules first: who can write, who can read and what can never change. Then we would build those rules and the links to utility and payment systems, and use the blockchain for the part that needs a shared record that shows tampering.
Georgia's land registry: proving that records have not changed
Georgia's National Agency of the Public Registry (NAPR) worked with BitFury to anchor a fingerprint of each land transaction on the Bitcoin blockchain.
Bitcoin
Public blockchain used for timestamps
Hash
Only a fingerprint of each transaction goes on the chain
1
System of record: the existing NAPR registry
The Situation
Officials could still change land titles, and the public doubted the integrity of the database. NAPR wanted protection against manipulation from inside and attacks from outside.
What They Did
BitFury built the system with NAPR, and New America's Blockchain Trust Accelerator gave strategic support. Each land transaction gets a cryptographic hash that is uploaded to the Bitcoin blockchain with a timestamp. The existing registry stays the system of record, and its front end was left unchanged.
The Reported Result
The timestamped hash shows that a record has not changed since the transaction was authorized. The system extends to sales, new registrations, mortgages and rentals, demolitions and notary services. The write-up gives no count of titles.
This pattern suits companies that already have a working database. Keep the database and anchor a fingerprint of each important record on a blockchain. We would add this behind your current software, so staff keep their screens and the proof layer runs in the background.
In a 2017 pilot, MIT offered digital diplomas on the Bitcoin blockchain, built with Learning Machine on the open-source Blockcerts toolkit.
111
Graduates offered a digital diploma in the pilot
Hash
Only a fingerprint and timestamp go on the Bitcoin blockchain
Instant
Check by link or file, with no call to the Registrar
The Situation
MIT wanted students to own and share their records easily, and to make it simple for others to confirm a degree is genuine without burdening the Registrar's Office.
What They Did
Students used the Blockcerts Wallet app from Learning Machine, which creates the student's key pair. MIT records a one-way hash of each diploma, with a timestamp, on the Bitcoin blockchain. The diploma contents are not on the chain.
The Reported Result
An employer or school can paste a link or upload the diploma file in MIT's credentials portal. The portal finds the blockchain record, checks the keys and confirms the diploma has not changed, immediately and without contacting the Registrar's Office. The pilot covered 111 graduates: 85 from the master of finance program and 26 from media arts and sciences.
For certificates we would put only a hash and a timestamp on the chain and keep personal data off it. We would build the verification page first, because that is what employers and schools will use. Our in-browser blockchain demo shows the same hash-and-check idea.
Estonia: an audit trail for patient health records
In 2016 Estonia's e-Health Foundation partnered with Guardtime to add a blockchain-based audit trail to patient health records.
1M+
Healthcare records in the database covered by the integration
2011
Year KSI began securing documents at select agencies
2016
Year the e-Health partnership was announced
The Situation
Patient records are changed by many people over time. The foundation wanted to be able to show that nobody had altered a record or hidden a change.
What They Did
Guardtime's KSI blockchain was to be integrated into the Oracle database the foundation uses, to give an independent audit trail for the life of each record.
The Reported Result
The partners said this would let the foundation monitor the integrity of its records in near real time and react quickly to incidents. The public announcements do not give measured results or say exactly what is written to the chain.
Project by Estonian e-Health Foundation and Guardtime. Facts from e-Estonia and SiliconANGLE .
How GTS would build it
For sensitive data such as health records we would keep the records in your database and put only proofs on a blockchain, so private data is never published. We would also check which privacy laws apply before choosing a design.
OrgBook BC: verifiable business records for the public
The Government of British Columbia runs OrgBook BC, a public service where anyone can check that an organization is legally registered.
1.4M+
Active legal entities listed (as of June 2021)
3.8M+
Verifiable credentials (as of June 2021)
2
Credential types: registration and permits or licenses
Open
Source software on Hyperledger Aries and Indy
The Situation
Customers, partners and government offices need a quick, trustworthy way to check whether an organization is registered and what permits it holds.
What They Did
The Digital Identity and Trust Program built the public website with BC Registries, which issues organization records as verifiable credentials. The Liquor and Cannabis Regulation Branch issues permit and license credentials against registered organizations. The service uses Hyperledger Aries and Hyperledger Indy, runs on Kubernetes, and the software is open source.
The Reported Result
Anyone can check whether an organization is registered, see its business number and registered "doing business as" names, and get notified of changes. Credentials usually update within minutes of a registration change. The latest counts on the page are from June 2021.
Project by Government of British Columbia. Facts from Digital BC .
How GTS would build it
For records that many parties read and one authority writes, we would design who issues each credential, how it is revoked and how a verifier checks it. We would build the search page and an API first, so existing systems can use the data from day one.
Project Ubin: five phases of testing blockchain for payments
The Monetary Authority of Singapore ran Project Ubin with industry from 2016 to 2020 to test blockchain for clearing and settling payments and securities.
5
Phases between 2016 and 2020
6
Project reports published
40+
Firms gave input in the final phase
3
Platforms tested: Corda, Hyperledger Fabric and Quorum
The Situation
MAS wanted to understand whether blockchain and distributed ledger technology could lead to simpler, more efficient alternatives to today's payment and securities systems.
What They Did
Each phase asked one question. Phase 1 tested tokenized Singapore dollars. Phase 2 built three prototype models for decentralized interbank payments and released the source code as open source. Phase 3 tested simultaneous exchange of tokenized currency and securities with the Singapore Exchange. Phase 4 linked Singapore and Canada for cross-border payments. Phase 5 built a multi-currency payments network prototype with Temasek.
The Reported Result
The project produced six reports and concluded in 2020. In May 2019 MAS and the Bank of Canada ran a successful cross-currency experiment, and the final phase took input from more than 40 firms.
We would run a blockchain idea as a series of small written experiments, as Ubin did: one question per phase, one platform comparison, and a report at the end. You would get a clear answer on whether to go ahead before paying for the full build.
The Ethereum Merge: changing how the network is secured
On 15 September 2022 Ethereum switched from proof of work to proof of stake in an upgrade called the Merge.
99.95%
Estimated drop in energy use
0
Actions needed from holders and users
10%
More frequent blocks
The Situation
Ethereum's original execution chain was secured by miners, while a separate proof-of-stake Beacon Chain had been running alongside it.
What They Did
The Merge joined the two chains. Afterward, validators who stake ETH secure the network instead of miners.
The Reported Result
Energy use fell by roughly 99.95%. Holders and users did not need to do anything, and balances, history and wallets kept working. The Merge did not change fees or network capacity, and blocks arrive about 10% more often.
Large upgrades need rehearsal on test networks, a clear rollback plan and plain messages to users. If your smart contracts depend on a chain that changes, we would test them against the new rules before the change date.
Uniswap is an exchange built from smart contracts. Traders swap tokens against pools of tokens instead of against other traders' orders.
x × y = k
The rule that sets the price in a pool
Pools
Traders swap against token reserves, not an order book
Anyone
Can add tokens to a pool and earn swap fees
Open
Source, permissionless contracts that are not upgradeable
The Situation
A traditional exchange needs a company to run an order book and match buyers with sellers. Uniswap asks whether the exchange can run as public rules instead.
What They Did
Each pool holds reserves of two tokens. After every trade, the product of the two balances must stay the same or grow, and that rule sets the price. Large trades relative to the pool move the price more. Anyone can deposit a pair of tokens into a pool, and swap fees accrue to the people who supplied them. In versions 3 and 4 the rule applies within each provider's chosen price range.
The Reported Result
There is no matching engine and no operator. Because the contracts are open source, not upgradeable and permissionless, no company runs the exchange, can pause it or can reverse trades. The documentation does not cover liquidity provider risks such as impermanent loss.
If you want rules that run without an operator, we would write them as small smart contracts in Solidity and test every rule. We would recommend an independent audit for contracts that hold real value. Our escrow demo shows how fixed rules reject the wrong person or the wrong order.
150,000+ 3D LiDAR Frames with 99.8% Precision for Autonomous Fleet
When a Tier-1 automotive customer pulled AeroVision's autonomous vehicle perception timeline forward by two weeks, GTS mobilized a dedicated second shift to label and QA over 150,000 complex 3D LiDAR point cloud frames without compromising safety tolerances.
150k+
3D Point Clouds Labeled
99.8%
Precision Rate
2 Weeks
Early Delivery
0
Safety Critical Errors
The Client Challenge
AeroVision required dense 3D cuboid annotations with temporal track IDs, heading angles, and velocity vectors for multi-class obstacles (pedestrians, cyclists, trucks, emergency vehicles) across rainy nighttime test drives. Previous offshore vendors had failed to exceed 92% accuracy, stalling model convergence.
The GTS Engineering Solution
GTS deployed a specialized 40-member computer vision pod trained on custom spatial annotation tools. Each frame was projected across synchronized 2D RGB cameras and 64-channel LiDAR point clouds, passing through a multi-tier human review process before batch export in KITTI format.
The Measurable Result
The labeled datasets boosted AeroVision's perception model mean Average Precision (mAP) by 14.2%, allowing their self-driving prototype to pass strict automotive OEM safety clearances two weeks ahead of schedule.
"GTS stood by us around the clock. The annotation team mobilized a dedicated second shift, delivering over 150,000 3D LiDAR point cloud frames with 99.8% precision. It felt like they cared about our vehicle launch as much as our internal team did."
Comprehensive penetration testing and infrastructure hardening for a diagnostic lab network handling over 250,000 confidential patient medical records monthly.
45+
Web Endpoints Tested
100%
Vulnerabilities Patched
HIPAA
Certified Baseline
0
Data Leakage Events
The Client Challenge
Ahead of their Series B funding and nationwide expansion, HealthTech required an exhaustive ethical hacking audit to uncover vulnerabilities across their patient portal, API microservices, and Amazon Web Services (AWS) database configurations without disrupting daily diagnostic telemetry.
The GTS Engineering Solution
The GTS security team performed white-box and black-box penetration tests, identifying three critical business logic vulnerabilities in their token authentication service. Harsh Joshi and senior engineers conducted developer debriefing sessions, delivering code-level remediation diffs and Docker container hardening.
The Measurable Result
HealthTech remediated 100% of discovered vulnerabilities within 10 days, passed independent HIPAA compliance audits with flying colors, and received GTS's official Security Clearance Certificate.
"In digital healthcare, a security flaw can devastate patient trust. GTS didn't just dump an automated scanner PDF on us. Harsh and his engineers sat with our dev team for multiple sessions, patiently walking through every code-level fix until our entire infrastructure was airtight."
Dr. Sunita Sharma
Chief Technology Officer, HealthTech Diagnostics
Client projectFintech & Banking
AuraPay Financial Network
Mumbai, India
Custom Software Engineering & Architecture
Custom Subscription Asset Management Platform (SAMS) with Real-Time Reconciliation
Engineering a bespoke Subscription Asset Management System (SAMS) eliminating third-party per-seat SaaS costs and synchronizing high-throughput recurring financial billing.
100k+
Daily Transactions
<20ms
Reconciliation Latency
100%
Source Code Handover
30-Day
Hyper-Care Included
The Client Challenge
AuraPay was spending over $4,500/month on generic subscription management software that lacked multi-currency reconciliation and could not handle customized split-settlement logic between Indian banks and overseas partners.
The GTS Engineering Solution
GTS designed and engineered a custom React + Node.js + PostgreSQL platform with role-based access control, automated ledger balancing, and webhook alerts for failed gateway transactions. The delivery included 30 days of round-the-clock post-launch hyper-care.
The Measurable Result
AuraPay eliminated recurring SaaS license costs, cut accounting reconciliation turnaround from 3 days to under 5 minutes, and achieved 99.99% system uptime during peak festival billing volumes.
"Most software consultancies invoice you and vanish. GTS gave us 30 days of round-the-clock hyper-care after our subscription asset system went live. When we faced a third-party gateway timeout on a Sunday evening, Harsh stepped in directly and resolved it within 20 minutes."
Rajesh Singhania
Managing Director, AuraPay Financial
Ready to Plan Your Project?
Tell us what you want to build. We reply with a written scope and quote, and we say so when a simpler option is enough.