Developer Culture at Giftbit: How We Build Our Gift Card API

Our developer culture at Giftbit is the reason our API works the way it does. From our earliest days, we’ve built with a mindset of simplicity, good faith, and reliability. The result is a digital gift card API that integrates quickly, behaves predictably, and helps your rewards program run smoothly, without extra overhead or hidden risks.

Leif Baradoy, our co-founder and CEO, likes to say we ‘craft our work.’ That culture has carried us through more than a decade of steady product growth. It shows up in how we design our gift card API features, how we support customers, and how our engineers take ownership of their work. 

I’ve seen how developer culture shapes outcomes. Our team is focused on craft, not on cutting corners or chasing trends. We build software that behaves the way the documentation says it will. Security practices are second nature, not bolted on later. Transparency means clients can see how things are working in real time.

When I think about our engineering team, I think about ownership. When a dev builds something, they stay close to it. They’re the first to respond if it doesn’t work as expected. They’re invested in making it right. That sense of responsibility and good faith is what defines our developer culture.

In this article, I’m sharing how that developer culture guides the way we build at Giftbit. You’ll see how our values shape our engineering practices, and the way we take ownership of what we ship.

Our developer culture at work

The way you build software matters. At Giftbit, our developer culture is about crafting code and security by default. We own what we ship. One of our co-founders was an engineer by training who cared deeply about reliability and security, and we’ve kept those guiding principles. 

We’re engineering software, we’re not just cobbling together code.

Simplicity has stayed core to what we are. From the start, we set out to make it simple to send rewards and digital gift cards. You’ll face real challenges and headaches if you try to run an incentive program and source distributors by yourself. We remove those challenges so you can get on with the work that matters.

We’ve also been transparent from the start, and for me that essentially means acting in good faith. I don’t like keeping something from our customers because there’s something to gain. If something is good for us, it should be good for our customers too. 

Of course, transparency needs context. You can lie with the truth if you present it in the right way. That’s why our product and our CX teams make sure it’s always clear what’s going on with your program, what the terms are, and how much you’re spending. 

Simplicity drives our gift card API

I care a lot about flexibility. When I’m assessing a vendor to work with, one of the first things I look for is their API documentation. Is it flexible in a way that lets me address the actual thing I'm trying to get done? Or do I have to fit into their world?

At Giftbit, we build an API that fits your workflow. We follow patterns that work, and we don’t take shortcuts on the basics. That shows up as:

• Idempotency that is truly idempotent.
  
  
• Fields are always returned in the formats we say you will get.
  
  
• Behavior matches the docs. The implementation and the documentation line up.

We’ve had developers sign up for a testbed account, build a full integration, and ask for production access within two days. That is one of my favorite compliments for the API because it highlights how easy it is to integrate.

There’s a real craft that went into the API. When you implement it, it behaves exactly the way you would expect.

Software developers who act in good faith

You shouldn’t have to guess how your gift card distributor works or what you are paying for. 

When I’m assessing vendors, nothing turns me off like a piece of software that says ‘call Sales for pricing.’ If I can’t get what I need from your website or docs, you’ve simply added friction for your own gain. That is not good faith. That is not how we work.

We care about the good faith terms of our agreements with customers. 

What this looks like for you:

• Clear information and self-serve paths wherever possible.
  
  
• Terms that match how we actually run the system so you can verify them.
  
  
• If outcomes don't match your expectations, we'll help you figure out why (and always provide robust gift card program tracking and reporting  so you can monitor your program closely).
  
  

Naturally secure development

I’ve been with Giftbit for over ten years. From the beginning, our engineering culture has been built around reliability and security. We craft our work. We slow down where it counts. We use best practices. Security is how we build, not a bolt-on.

So much of security is about best practices. Those are just default for our engineering team.

This shows up in habits and checks you can count on, like:

• Encryption in transit and at rest. Always.
  
  
• High-entropy identifiers that are hard to guess and brute force.
  
  
• Least privilege. Thoughtful scopes and access by default.
  
  
• Threat assessments on what we build.
  
  
• AWS controls with redundancy and strong defaults.
  
  
• Minimized data movement. We only move what we need.
  
  
• Sensitive fields are further encrypted. This level of added security is especially important for academic research payouts with strict regulatory standards. Even if someone somehow got their hands on a raw copy of the database, the PII is still encrypted. They’d still need a separate key to access it. 

We also work with you on setup. During API approval, we flag where risk can enter your flow, like in how you store links or collect addresses. We understand that digital rewards aren’t everyone’s full-time business. So we share tips and best practices to make your program safer and more successful.

Of course, we’ve always been PCI compliant, because we distribute prepaid cards (i.e. prepaid Mastercard® and Visa® incentive cards). 

We also became SOC 2 compliant to make our practices clearer and more legible for customers and leads. Like I’ve said, from Day One we’ve built to strong security patterns. I saw SOC 2 as a priority because it really helps our customers get started faster. It's essentially a summary by an independent auditor that clearly describes the safety protocols we have in place and demonstrates that we maintain certain standards. 

The goal was simple: to turn what could be a two-week security review into a few hours with our annually updated SOC report. 

Ownership, collaboration, and continuous learning

Software developers own their work at Giftbit. If you built it, you stay close to it. You shepherd it through QA. You test with stakeholders. And you are the first to respond if something in the wild doesn’t work as expected.

I like the way the team talks with each other, because it’s a truly collaborative community. We don’t have silos here (or at least we try not to). And anyone can ask the ‘Naive Question.’ Even if you don’t fully understand a part of the system, you always have the right to ask if we considered the non-obvious thing. We keep each other high context on what everyone else is building. Everyone wants to understand the whole system. 

It’s rare for things to really break here. When they do break, it comes from unexpected behavior, not because someone was careless or missed the obvious. That is what good craft gets you.

Everything we do, we do fully. 

How we plan and work: our strategy from backlog to spikes

My product roadmap work always starts with a strategy conversation. Six to twelve months out, I’ll meet with our leaders to see where we’re trying to go. Then I look at the backlog along with the voice of our customers. Matt Brossard, our Director of Business Development, and Sofia Baltasar, our Head of Customer Success, are great at listening carefully to our clients to help us figure out what will serve them all best. 

From there, we pick work that serves the strategy. Are we growing a particular market? Are we enhancing a certain use case? We choose features that move those goals forward. 

We’re fortunate because we’re in the B2B software space, where sales cycles tend to be longer. That gives us time to build strategic features in the right way. Built into that time is enough flex to jump on bugs or small wins that remove friction for a customer. 

To learn fast and stay responsive without breaking focus, we use spikes as needed:

• We flag work as a spike when we’re not sure how complicated it is.
• An engineer gets three days to work on it.
• If they come up with a great solution that fits our strategy, they get the go-ahead and ship.
• If not, we’ve protected the roadmap without wasting time, and learned something new in the process.
  
  

Asking “what if” without losing focus

Another tool I like comes from a designer we worked with. We call it ‘how might we.’ It’s a great way to explore an idea without committing too firmly to a new path. 

Maybe there’s a new AI model or something new with blockchain, or we’ve seen another software provider do something interesting. We give ourselves permission to consider the possibilities. How might we implement this for our customers? How might we add business value with it?

If an idea passes security and value checks, we might run a small spike.

If it doesn’t, we keep it parked, maybe add it to the backlog, and otherwise stay focused on the roadmap at hand. 

Reliability and craft over trends

My goal is always an API that is flexible and easy to understand. We keep patterns consistent and we do the basics well so your team can move with confidence. Our API should fit your workflow.

There’s nothing fly-by-night about what we do. I like working in a culture that takes pride in what they do and what they offer. 

Of course there are some really interesting opportunities around AI, and we’re all paying attention to it. And of course everyone on the software team is playing with different tools and building code generation into how they can move quickly. But then our security culture comes in, because you can’t automatically trust the output of an AI code bank. 

Remember that AI is learning our language. If we write documentation that is straightforward for a human developer, AI will be able to understand and use it too. 

And the basics don’t change. Code should be easy for the next developer to understand. It should work reliably. If something goes wrong, it should be clear what happened. That's what I mean by 'craft.'

Our devs don’t like half measures. We don’t like shortcuts. If we do take a shortcut, we commit the resources to shore it up on the other end. That’s why people can rely on our API.

Giftbit’s team culture day-to-day

Our software engineers are collaborative owners who feel responsible for the code they’re putting out in the world. They’re open to new ideas, they’re highly professional, and they’re also just good people to be around. 

Day-to-day, this team culture looks like:

• Deep feature work with room for fast fixes. Long horizons for strategic features. Quick responses for small wins that remove friction for customers.
• Security standards by default. Least privilege, threat assessments, encryption, and idempotency are table stakes.
• Clear processes from strategy to backlog to spikes, with focus on timing and customer value.
• High ownership. If you build it, you’re the first responder because you often get there first. 
• High context. Anyone can ask the Naive Question. We keep the whole team in the loop.
• A growth mindset. We aim for small, steady gains that compound over time.

How software teams impacts your API

Developer mindset and culture shows up in the API you run in production. When you send gift cards and prepaid cards, you’re dealing with money and trust. The wrong API creates rework, support tickets, and risk. The right one keeps the basics safe and dependable so your team can move quickly.

I want an API that behaves the way the documentation says it will. That is the bar we set for our own API, and it's why our customers can integrate so quickly and stay confident. 

Questions about building into our API? Chat with Sales. Ready to get started? Sign up for your free testbed account. 

Giftbit’s culture, defined: a glossary of terms

AWS controls
We use managed security features and redundancy from AWS. Defaults are strong and reviewed.

Compound improvement
We aim to be a little better, again and again. Small gains add up.

Consistent payloads
Fields are returned every time in the formats we promise. Docs match behavior.

Craft
We engineer software with care. We slow down where it counts. We follow patterns that work. And we don’t take half measures.

Encryption in transit and at rest
Data is protected when it moves and when it sits in storage. Sensitive fields are further encrypted.
Why it matters to you: 
Even if someone held a raw database copy, private data would still require a separate key.

Event streams
The sequence of actions in the system. We watch these to spot patterns and surface non-obvious fraud signals.

Good-faith transparency
We give you the full picture with context and real-time insight into your programs. We do not hide terms or decisions. You can verify what we say.

High-entropy identifiers
We use IDs that are very hard to guess. This makes brute forcing a single reward impractical for bad actors. 

Idempotency
You can send the same API request more than once and you get one clean result. No accidental duplicates.
Example:
You retry a create call after a network hiccup. The action is not repeated and no extra reward is created. This is incredibly important when real money is involved. 

Least privilege
Services and people only get the access they need, and nothing more. This limits blast radius if something goes wrong.

Ownership
If you build it, you stay close to it. You shepherd it through QA. You test with stakeholders. You quickly take responsibility if something breaks.

PCI compliance
Required controls for handling prepaid cards that are part of protecting cardholder data.

Pragmatic AI
Use AI where it helps: drafts, code generation, pattern spotting. Always verify the output.

Readable code
Code that is easy for the next developer to understand.

Self-serve, low friction
Clear docs let you try out the API fast. No obscure pricing. No “call sales” wall.

Simplicity
We remove headaches so you can send rewards without friction. And our API works just like our docs say it does. 

SOC 2
Independent audit that shows how we handle security, availability, and process. It turns a long vendor review into a faster audit read.

Spike
 A small, time-boxed investigation. We give an engineer up to three days to learn the shape of a problem. If a clean solution appears, we ship. If not, we protected the roadmap.

The naive question
 Anyone can ask the simple question that exposes a hidden risk. No ego. High context across the team.

Threat assessment
We ask what could go wrong before we build and before we ship. We note potential risks and plan mitigations.