A place where we write words Ignition Blog

Welcome to the Ignition Development blog, where we talk about a wide range of technical and non-technical topics.

Site Foundation Framework for indie software developers

Posted on Thursday, March 04, 2010 9:09 PM

The old Tentacle Software website wasn’t a looker by anyone’s standards; it functioned, in that it served HTML pages with text and links, but it was by no means a stunning piece of architecture. In fact, it was just a couple of raw HTML pages and some JavaScript.


In the run-up to launching Disk Management, we redesigned the site using a free CSS template and switched to Ignition Development’s Site Foundation Framework for content management and shopping functionality. Why SFF? Well, you can’t run a successful store on a crap CMS, and I helped write SFF so I know it’s awesome.

Ross Hawkins has a post describing the thought processes behind the decision to write our CMS from scratch, and I agree with it all; we know the code inside and out, so completely gutting, say, the payments system and plumbing in an entirely modular replacement is actually doable in a reasonable time frame. Can you guess what I did to the codebase to get PayPal integration working?


We built SFF with YAGNI firmly in our minds. We supported a single New Zealand payment provider for the shop, and had a static workflow for orders. Given that the first few commercial sites built on SFF were New Zealand retailers, selling similar physical goods, the single approach was sound and delivered great solutions for our customers.

Tentacle Software sells internationally, and the most accepted international currency for our audience is U.S. Dollars. It’s surprisingly hard to bill in U.S. Dollars (specifically, to charge credit cards in USD) from New Zealand; only one bank provides the service, and their setup and transaction fees are high for a small business.

We also don’t ship physical products, we sell license keys and deliver them via email instead.

This all ends up with our small little web store requiring some big changes to SFF:

  • Pull out the existing payment provider and replace it with PayPal
  • Change the ordering process to integrate with our licensing engine, generate a license key and email it to the customer
  • Drop all references to shipping addresses and only care about billing addresses

PaymentProvider and PostProcessor model

Rather than take a branch of our codebase and just hack things into shape, we decided to bite the bullet and re-architect the ordering workflow to make it more modular and to make our lives easier the next time someone wants to send, say, a telegraph on order completion.

We built an order processing engine that contains a list of PaymentProviders (which could include PayPal, our original payment gateway, and/or some other provider we haven’t run into yet) to present to the customer at checkout, and a list of PostProcessors that process each successful order in sequence (to generate license keys, send notification emails etc.).

Where previously we had hard-coded payment steps, we now have a pluggable workflow that grabs configuration out of web.config to populate a list of payment providers and postprocessors on application start.

This makes our customizations for individual customers much more portable, and upgrading their sites much, much easier. If the customer needs to send a pick-list to a 3rd-party manufacturer for each successful order, we can write that custom module and easily inject it into the order workflow.

I thought it was going to be an arduous task to essentially gut the store and rebuild it from scratch. But the architectural choices we made to begin with, while we did embrace YAGNI, meant that SFF was built with future extension as a core requirement. The abstractions we used between layers of the application made the refactoring process straightforward and relatively painless.


The infrastructure customizations for Tentacle Software were just a matter of writing a PaymentProvider and IPN Handler for PayPal integration, and a PostProcessor to attach a generated license key to the order.

We also moved a bunch of control definitions to web.config and replaced them with interface definitions in the code-behind for each page. This meant I could write my address controls to ignore shipping addresses and not have to worry about recompiling the main SFF instance.

Once Ross had pushed our chosen CSS template into the master page (thanks Ross!), everything just worked. Obviously, I’m skipping the hours of CSS tweaking to get the box model working in every browser, but I think we can all take that as read.


All this tells me that we built a pretty awesome framework that’s easy to extend. Score one for “build it yourself!”

We’re looking at the option of selling SFF + TentacleLicense as an instant web store for indie software developers. One of the things that delayed Disk Management for so long was getting the license and ordering process working, I was too busy maintaining the existing version of Disk Management to really put time into it.

I think that’s going to be the barrier for a lot of small software development teams who have a great product but no time to write the infrastructure to actually sell the thing; we all spend too much time posting in our own support forums and not enough time writing code.

If you’d like to know more about our as-yet-unnamed software store in a box, get in touch.



No comments posted yet.

Would you like to post a comment?

Post title
Your name
Your email (optional)  
Website (optional)

What do you want to say?


Please add 1 and 7 and type the answer here: