As a software house, SpiffyMap offers our services to build software or websites for our customers. From major e-commerce systems handling tens of millions of pounds of business, to small-scale websites based on an easy-to-learn content management system, we have experience of building web software going back to the mid 1990s. We also have considerable commercial experience of running training courses, teaching, mentoring, consultancy and software project management.

While we have map/chart display focus for our own products, we are open to tendering for any type of project requiring UI work, server-based systems and an API between the two. (We're just especially interested if it involves maps because we love maps!) We have expertise in building user interfaces for the web, for desktop applications and for mobile devices, and we have our own proprietary technology which makes it easy for us (and therefore cost-effective for you) to build user interfaces which work across more than one of those types of user interface.

Key technologies

Our key technologies are Java and GWT, and while we do sometimes use other languages, most of our focus is on Java because of its power, scalability and testability on the server-side. For those not familiar with GWT, see our introduction About GWT. In a nutshell it's a powerful tool for building user interfaces in fully testable XML and Java which can then run in web browsers and on mobile devices such as phones and tablets.

We have delivered projects using Java with most of the popular relational databases such as MySQL, Postgres and Oracle, but we also have experience with NoSQL databases, specifically object databases which provide amazingly fast, transactionally reliable (ACID) storage for Java systems. We found this approach essential for our own map systems handling huge volumes of geographical data but we now apply these technologies to other projects.


We practise a form of agile development - not a specific formal method, but ideas taken from the fields of agile development and lean startups as we feel appropriate. A key characteristic is that this involves liaising with the customer throughout the development process to resolve questions and flag up potential problems as work progresses. (As opposed to simply implementing a monolithic "specification" agreed in advance which is now known as “waterfall” project management.)

This way of working lends itself better to working to an estimate rather than to a fixed quotation, and this is how we prefer to work. Although we will in some circumstances work to a fixed quote, because software development time is so difficult to estimate*, fixed quotes involve risk and for small companies this risk needs to be shared. This takes the form of “padding” the quote with some contingency margin in case things take longer than expected; all software companies who work to fixed quotes do this (as do companies in other realms such as builders). We find that our customers benefit from the transparency of us providing an estimate, in the form of an agreed minimum and maximum cost. Since we keep the customer involved as development progresses, we can easily flag up any potential over-run above the agreed maximum and make a decision as to how to address this at the earliest possible time. We also provide milestones and, where appropriate, access to prototype user interfaces.

* the difficulty of software estimation has been shown in studies over many years, but for a more light-hearted explanation, see our page why software development is like measuring the coast of Britain.