Putting Loyalty Points on Ethereum in One Month
Executive Summary: A loyalty startup needed to show that its users’ points could not be deleted at will, and had about a month before presenting at a blockchain conference. I had never worked with blockchain. I first automated disposable test servers that synced to the Ethereum network and deleted themselves to save cost, then used them to iterate on a smart contract. By the conference, every point in the app was distributed through that contract on the live network.
Context
The product was a loyalty app: users earned points when they shopped. As a new company it had a trust problem. In some loyalty programmes points expire, and users had no reason to believe that a young startup would not remove theirs.
Management proposed keeping the points on a blockchain. They were also due to present the startup at a blockchain conference about a month later. At the time I did not know how a blockchain worked.
Decision
Why a blockchain. There were two reasons. On the technical side, a database could not prove that points were never removed, because we controlled the database; a record that cannot be changed and that anyone can verify could. On the business side, blockchain had a lot of attention at the time, and a new startup could use that.
Test infrastructure first. I expected a lot of trial and error, so before writing contracts I automated the environment. With Chef, I wrote a setup that created single-use test servers, synced them to the Ethereum network, and let them delete themselves afterwards to keep costs down.
Iterate on disposable environments. I developed and tested the smart contracts on those quick, cheap servers. Then I wrote the contract that distributes the points and deployed it to the live Ethereum network.
Consequences
- Positive: About a month after starting with no knowledge of blockchain, the contract was live. Before the conference, all points in the app were distributed through it on Ethereum.
- Positive: At the conference, most startups described what they planned to build on a blockchain. This one could show what it was already running.
- Negative / Cost: Part of a short month went into infrastructure before a single contract existed.
- Negative / Cost: A contract on a public network is hard to change once deployed, so a mistake in it is expensive to fix.
When to revisit
Building disposable environments first fits any unfamiliar technology where many experiments are expected and each environment is slow or costly to set up. The blockchain itself is worth revisiting when users do not need to verify the record independently: a database with an audit log is then simpler and cheaper to run.
This case note is an anonymized Architecture Decision Record (ADR) from a real-world engagement.