1. Stanford University and local high-paying employers attract the best ambitious technical talent, and facilitate immigration through visa programs. The rigorous interview process for these institutions acts as a first-round filter for investors.
2. Entrepreneurs form startups during their academic studies or use savings/equity from their well-paid jobs.
3. Initial seed funding is readily available from a large network of angel investors. As we’ll see, these angels are likely to already have a shared connection with the entrepreneur.
4. Later rounds of funding are enabled by one or more local Venture Capital funds, who are also socially connected.
5. The startup is acquired by, or grows into a larger corporation.
6. The entrepreneur vests or otherwise significantly cashes-out of their company, with enough wealth to provide angel investment for smaller startups. As the entrepreneur originally came through the Stanford or Facebook/Google/etc route, they likely already have shared connections with many of the younger entrepreneurs.
7. The angel becomes a partner at a larger VC fund; now the fund also has a connection to the new startups.
8. The VC teaches a class or becomes a professor at Stanford, forming closer connections with / earlier access to future entrepreneurs.

I don’t want to imply that this is the only way that people and funds flow in Silicon Valley (SV), nor is it even the most common. But it does demonstrate one of the many people-oriented ecosystems that make the area unique. Other entrepreneur networks include those established by funds or accelerators. For example, I like to play my own version of The Kevin Bacon Game, called The Dave McClure Game, in which I connect any person in the Bay Area to Dave McClure (of 500 startups) within two steps.

I’ve lived in three different countries and travelled around the world, and a recurring theme in the web communities of large cities is a desire to replicate the successes and benefits of the SV tech scene. But these tend to focus on the wrong things, like shared office space or high-speed internet infrastructure. While these are certainly useful elements to have, they’re not the source of SV’s success – in fact, anyone who lives in SV will tell you that the internet infrastructure is surprisingly primitive.

It’s the feedback loop of people that makes SV what it is, from the constant influx of young global talent, through the huge experienced mentoring network, to the established investors and thought leaders. It’s a catch-22 born of previous successes.

Align all elements to a grid. Use a framework like 960.gs if you want, but you may find that the gutters between columns are too narrow or your page elements don’t fit neatly into the pre-defined grid. It doesn’t take much effort to set up your own self-consistent set of widths in CSS. You may find it easier if you:

• Use a CSS Reset declaration to more easily set up predictable spacing, especially if forms or lists are involved.
• Use a Clearfix hack on rows to avoid weird floating anomalies.
• Use box-sizing: border-box on your columns and display: inline-block on horizontal list items (e.g. menus) to make padding and margin adjustments easier. Remove any whitespace between inline-block elements to get the best results.

We created our own grid for Subpug

2. Color Palette

Choose a color palette and stick to it. You probably don’t need more than three colors, along with black and white.

• Don’t be afraid to use shades of your main palette colors. Once you have your main palette in RGB format, it’s easy to create shades with different opacities in rgba() CSS declarations.
• Limit the amount of gaudy fully-saturated colors in your palette. Even black and white should be a little desaturated; think #111 or #222 instead of #000, and #FDFDFD rather than #FFF.

3. Typography Hierarchy

Create a typography hierarchy and stick to it. Font size is the most obvious way to visualize the different priorities of text, but you can also use font weight, color and family.

• One font family is the easiest to get right; use two if you need the additional flexibility in your hierarchy. In general, combinations of font families should be dissimilar, such as a serif and a sans-serif, though of similar proportions.
• If you’re going to stick with a single font-family, you’ll get the most flexibility from a family with lots of weights to choose from. Helvetica Neue is great on a Mac; for consistency across all platforms, try Proxima Nova from Typekit or Open Sans from Google web fonts.

 4. Line Height

Set your line heights. It’s surprising how a small change to line height can make a block of text feel more professionally designed.

• Make sure that you know the difference between a line height of 1.2 and 1.2em.
• Try a line-height of around 1.4 to 1.5 for nicely readable paragraphs of text, and 1.1 to 1.2 for tighter headlines.
• If possible, keep a common multiple between your line heights to set a vertical rhythm. For example, a paragraph of 12px with 1.5 / 18px line height could be paired with a heading of 24px and 1.125 / 27px line height, both of which fit onto a base vertical grid of 9px.

5. Light Source

Define an invisible light source and apply its effects consistently. Most designs assume a dim ambient light source at some distance beyond the top of the page, but you could try different directions or even a brighter point of light directly “over” the page (i.e. from the user’s direction). The effects of the light source are:

• Solid blocks of color should be replaced with subtle gradients. If the light source is at a large enough distance from the top, a linear gradient should run vertically with a lighter top. Unless your virtual bulb is extremely bright, keep the gradients subdued, though big blocks of color will need a large enough gradient to prevent banding. If the light source is hovering over the page or is close to an edge, it should produce a radial gradient.
• Interface objects that have depth, such as buttons and hovering elements, will cast a shadow. For most subtle light sources, keep the shadows no more than a few pixels in offset and blur distance, e.g. box-shadow: 0px 2px 2px rgba(0,0,0,0.1), and don’t use pure black for the shadow color.
• Text that appears on a button or other interface element surface should be given depth, with a 1 pixel drop shadow. A dark text-shadow will make the text appear above the button, a light shadow gives the appearance of inset text.

We use a consistent top-down light source in Subpug

6. Realism

Add subtle realism to the interface details.

• Square pointy corners are sharp and painful, so most real objects tend to have slightly rounded corners – take the same approach to your UI elements with border-radius.
• Real-world objects tend not to instantaneously disappear, but instead fold, fade or slide away. Add transitions like -webkit-transition: all 0.4s (and other browser equivalent properties) to elements that move, resize or disappear.
• Materials are rarely perfectly smooth, so add a subtle amount of noise to your interface. You’ll have to apply noise with an image, but you can create a single tile-able noise PNG with alpha transparency and apply it to elements of different colors via multiple backgrounds, e.g. background: url('noise.png'), -webkit-gradient(linear, left top, left bottom, #E7ECF1, #D1D9E0)

In this upcoming app, we use a non-standard, subtle border-radius (border-radius: 2px 2px 20% 2px / 60px 2px 2px 60px) combined with an inset shadow for an asymmetrical paper effect.

7. Whitespace

Follow Dan’s maxim, “If it still looks bad, add more whitespace.”

Don Draper, the role model for serious businesspeople and sepia-lovers everywhere.

I’ve attended hundreds of sales pitches and client meetings, nearly always as a supplier to a larger organisation. On a few occasions in my early career I recall being faintly berated by colleagues for my behaviour. Not for doing anything aggressive, derogatory or suggestive, but for humorous remarks that were deemed inappropriate – just by the nature of them being a light-hearted quip said in an otherwise serious situation.

With relatively few exceptions, big businesses lack humour. Even smaller web startups tend to take themselves very seriously, and some of the most prominent technology journalists dedicate far too much of their time to personal vendettas and angry rants.

Why is it that our culture somehow associates fun and humour with a lack of professionalism, whereas if you’re solemn, loud and angry you’re taken seriously?

Many of my heroes are known for their wit: Stephen Fry, Al Franken, Jon Stewart, Chris Morris, Richard Feynman, Richard Curtis and Mark Thomas. Though, to be fair, they do all dodge the difficult issues of making profits and running businesses, and instead tackle easy targets like government corruption, the destruction of our ecosystem, corporate murder, third world poverty and the mechanics of our universe, to name but a few trivial matters.

These intellectual professionals demonstrate how humour can be used not to belittle an issue, but to clarify and amplify arguments, and increase the impact of their case. Research confirms [e.g. 1, 2] that humour helps people to remember things.

When I first started to learn the Ruby programming language, I stumbled upon Why’s (Poignant) Guide to Ruby. What a breath of fresh air it is, in the otherwise stodgy environment of technical programming guides, full of irreverence and whimsical cartoons. The author, why the lucky stiff, has/had a rare knack for mixing instruction and art to produce charming, memorable material. If you don’t already know about __why, you can read about his legacy at Smashing Magazine, John Resig and Wikipedia.

There is a time and place for humour, of course.

Most web app interfaces are purely functional and should be as transparent as possible, not interrupting a user’s flow with jokes and confusing pun-laden labels. But when we get a chance to communicate through other channels, whether in-person, through emails and blogs or instructional guides, humour should be considered a useful and professional tool that can be judiciously applied to relevant situations, not avoided at all costs.

And on that note, I’ll leave you with an always-excellent XKCD cartoon:

Most recently, the concept of a Minimum Viable Product (MVP) has been debated – does it mean a small first release, a barely-usable prototype, or even just a Google AdWord?

An MVP may or may not be any of those things – depending on how you’re using them – but it doesn’t really matter what the definition is. Like many good ideas, the concept of the MVP is more important than a rigid definition. Rather than trying to replicate other people’s tactical implementations of the concept, it’s better to focus on the beautiful strategy of the MVP approach: what it is trying to achieve.

Validated learning lies at the heart of MVP. This means that you should create something that enhances your knowledge (of the market or the problem space) using real data from customers or potential customers. Moreover, you must endeavour to extract the maximum amount of learning from the least amount of effort (money and time).

This is why the Google AdWord is a compelling implementation of the MVP: spend a few hours and a few dollars creating adverts, and you can learn about the market reaction to individual features, price demand curves, and even – if you’ve configured decent analytics on your landing page – the demographics and trends in daily usage patterns of your potential customers.

However, AdWords aren’t suitable for all cases. If your app is in a highly competitive market, you’ll either need to spend a lot more money to test it (and therefore an alternative MVP implementation may require less effort), or else it will languish on the second or third page of results, where it doesn’t receive enough attention for you to learn anything with confidence.

Similarly, if your app is in a new market, you may need more than the limited space of an AdWord to persuade early adopters to try it. If Twitter had tested an MVP AdWord, they would have received relatively few clickthroughs and may have decided to abandon the idea. Even a sophisticated mock-up or internal prototype may not have been a suitable MVP for Twitter, who would have needed a basic functioning system with the ability to post and read messages before they could discover anything about how early adopters used the product.

Don’t limit yourself to one specific MVP implementation if you can quickly and easily learn more through multiple sources; the MVP is an ongoing, iterative process, not a single definitive test of an idea. Depending on your market, you may decide to create an advert, send out a survey email and also present an annotated wireframe to the board of an interested corporation. When we first started to think about Clickdensity, we published early data on an O’Reilly blog to get feedback from alpha geeks, prototyped with a client to see how they used the results, and emailed our customers to assess their reaction to the proposition.

Which leads me to my final point: you need to carefully consider and perfect your app proposition before you test an MVP. It’s all too easy to get caught up in the idea of an app and assume that people will know what it does and why they should use it. For many forms of MVP, it is the text of the proposition rather than the interactive functionality of an app that’s being tested, so be sure to run your text past a couple of relevant people before testing it with a larger audience.

While the book includes some quick and easy ways to validate a concept, I don’t really talk a great deal about the initial genesis of ideas, as I assume that most people who buy the book already know what they want to build.

This post fills that gap. It is written for those of you who have the enthusiasm to build an app, but first need a good problem to sink your teeth into.

Work

Most of us spend at least eight hours of every weekday at work, solving problems, transferring knowledge and managing processes. Our wages are usually based on how quickly and effectively we can do these things, as quantity and quality are two key variables that affect business profits. If you can think of a way make a business process more efficient or generate more value in the same amount of time, you’ve got a fundamentally sound app idea.

Unfortunately there is little tangible diversity in the daily experiences of most web app developers. This is one reason why you see a steady stream of new MVC frameworks on Hacker News – we have similar jobs in similar environments, and therefore create similar solutions to similar problems.

Less than 1% of workers in the US are software engineers [data 1 and 2], yet we initiate at least 90% of web app products (a conservative guess). This is the equivalent of most magazines being written by printing press operators – though come to think of it, that would produce more interesting results than the current stable of celebrity cellulite shitfests.

It doesn’t necessarily matter if you pursue an unoriginal idea, but in some ways it makes it more difficult to have a real impact: you’ll face apathy from the market and a prohibitive amount of competition that includes free and open source options. Unless you’ve secured the funding necessary to force your way into a crowded market, it’s better to seek opportunities that at least have a smidgen of something new and that customers have a pressing need for.

If you work in a small company or startup, you’ll naturally wear many hats and will face a variety of non-technical problems. Keep your eyes peeled for tasks that can be automated or improved with web technology.

If you work in a large company you should seek out similar opportunities, but you’ll need to proactively find a way to work with other teams (sales, design, marketing, finance, human resources) to step out of the programming sphere and find fresh problems to solve.

As director of a growing web company for eleven years, I got to discover many problems that are still in need of solid solutions. Here are two examples to get you started.

Example: Responding to tendering opportunities is costly. Large contracts from the public and private sectors are often put out to tender. If a company wants to win one of these valuable contracts, they must respond with a high-quality documented response, which will run to hundreds of pages, though much of it can be boilerplate or customised boilerplate text and diagrams. The value of a contract is often hundreds of thousands of dollars, so it’s worthwhile for the company to spend days or even weeks preparing the tender response, which is incredibly costly, but a necessary risk of winning work.

Over time, a company will create dozens of boilerplate/template documents/answers/snippets that they can re-use in tender responses, but these are often stored in myriad Word documents that need to be manually managed, collated and customised.

There is an opportunity for an app that stores various reusable document components that can be easily discovered, selected, customised and aggregated to produce a tailored, professional tender response. If a company tenders for two projects a month and you can reduce the average tender response time from five days to three days, you’ll save them thousands of dollars a month, at minimum. What might a company pay for that kind of saving?

Example: Assessing good job candidates is difficult. There’s no obvious solution to this, which is why it’s still a problem. Every company knows that their hiring process isn’t perfect. They’ll take on employees who won’t pass a probationary period (costing the company thousands of dollars in wasted training) and will pass on candidates who should have been accepted (costing the company potentially tens of thousands of dollars in opportunity costs).

There are a few partial solutions to this problem (such as LinkedIn and Stack Overflow) but these are industry-specific and not applicable to all candidates. If you could develop an app that helps employers (perhaps in a specific industry) to improve their hit/miss recruitment rate by even 10 or 20%, you’ll save them thousands of dollars a year, and probably a lot more.

Life

When you’re not in work you’re cooking meals, paying utility bills, socializing, pursuing hobbies and fitness, seeking entertainment, traveling, and so on. Adopt a critical mindset for a couple of days to identify areas that could be improved, bearing in mind the types of task that web apps are useful for, such as automating recurring processes, detecting patterns in data and bringing together supply and demand.

Think creatively, and question anything that doesn’t seem quite right from the second you wake up. Feel tired after a restless night? Maybe there’s a way to detect a pattern in your habits and environment to improve your sleep. Throwing away junk electronic equipment because it’s not worth your time putting it on eBay, Craigslist or Freecycle? Perhaps there needs to be an exceptionally low-friction app that can list it for local pick-up within seconds. Annoyed at the garbage that people leave on your street? There may not be a web app answer to that, but maybe there is if you give it some thought. It sometimes helps if you first consider what the perfect “magical” solution would be, ignoring technical limitations. From there, work back to the closest you can get with current technology.

Here’s a more concrete example.

Example: The system for buying gig tickets is broken. We all know it. Many popular venues only list tickets through large corporate ticket vendors, and the final price always seems to end up costing 50% more than the “face value”. There are some complexities at work here (it is often the venues that impose the ridiculous additional fees, not the middle-men), but that doesn’t make the system any less broken to the customer. In addition there are people who buy multiple tickets for no other purpose than to restrict supply and inflate the re-sale value of their own tickets.

So, while there are a number of upcoming gigs at The Fillmore that I would like to attend, I’m not willing to pay the absurd extra fees for bands that I’m only partly interested in seeing. What some of my friends and I do is wait until a day before each gig and then scan Craigslist and eBay for spare tickets. For most gigs, we’ll find tickets at face value or sometimes less. However, we still have to manually set a reminder for upcoming gigs and then scan the websites for tickets a day or two before (or sometimes on the day of the gig itself). An app could make this more efficient, by helping to match supply and demand.

Competition

If your primary purpose of building an app is to make money, it sometimes makes sense to copy an idea that’s already proven rather than strive for originality. As Zynga’s CEO Mark Pincus is alleged to have said, “I don’t fucking want innovation. You’re not smarter than your competitor. Just copy what they do and do it until you get their numbers.”

You could investigate small (easy to replicate) profitable web apps and copy them feature-for-feature, but for reasons I’ve already stated, I’m not a fan of blatant facsimiles. If you can add a slightly new take on a tired concept you stand a better chance of success.

A simple way to do this is to find a large piece of software and think about how it might be adapted to better suit specific industries; Eric Reis and Steve Blank would refer to this as re-segmenting a market by niche.

Think of how Kyle Bragger’s Forrst took the idea of a generic social network and re-segmented it for graphic designers and programmers. How would you do something similar for your occupation or interests, such as a social network for musicians to share riffs and ideas?

Example: Basecamp for authors/publishers. 37 Signals’ Basecamp is the leading project management and online collaboration tool, partly because it’s well-designed generic features make it useful for a wide range of industries. But this also means that it isn’t tailored to any particular type of business.

My publisher, editor and I used Basecamp to communicate throughout the book authoring process. While it certainly helped, it could have been improved for our particular use-case. Small publishers and distributed authoring teams need a system that better handles revisions between files, and in general something more suited to iterative tasks rather than linear discussions. It would also be useful to have a file repository that treats various assets – documents, diagrams, screen captures, raw data, sources – differently, and one with greater control over the structure and relationships of discussions, files, milestones and to-dos. But it also needs to be extremely simple and tailored for the publishing process, not just a shoe-horned version of GitHub or Redmine.

Even Magma, which handles “print publication management” and according to Techcrunch is a “Basecamp-like platform oriented towards magazines and print publications”, is aimed at a slightly different segment of the market. There are abundant niches to fill in almost every market.

Technology R&D

Sometimes an idea will present itself when you’re playing with technology. In the winter of 2005 I was tinkering with some simple Javascript that displayed the X and Y coordinates of the mouse position, and started to think how interesting it would be to record the coordinates of a user’s mouse on a website. We quickly created some prototype code, and found that the results were actually useful. That code went on to become what was probably the first heat map app, before Crazy Egg, Clicktale and the others that followed.

This isn’t my preferred approach to idea development because it’s technology-led rather than originating from a real market need. Still, it might help to get your creative juices flowing. A quick way to start thinking about the application of technology is to write a list of recent web technologies that interest you on a piece of paper – web P2P video, canvas/WebGL, geolocation, data mining algorithms, and so on – randomly choose two (close your eyes and place your finger on the list), and think about how they could be usefully combined.

Market R&D

What do people say that they want? Social media and web apps like The Internet Wishlist make it easy to find out. Check out Google search suggestions to discover what software people are looking for (e.g. 1, 2), and try creating some convoluted Twitter search queries to find tweets with app ideas. Most will be in jest, but you’ll sometimes find some genuine needs hidden in the noise, and even the humorous suggestions can inspire a practical related app idea.

Summary

This post outlines different sources of inspiration for web apps. Once you’ve chosen an idea, give it a few days to mull-over and slowly iterate the concept. Rather than gradually expanding on the initial idea, try to stick to the essence of it while you remove imaginary features and scope. Most of all, try to choose an idea that excites you – it makes the development so much easier.

A quick additional note on the methodology. For the ratio data (most men, women, tourists, locals), I only included venues that had received over 200 checkins during the data collection period. In total, the data consists of about 500,000 checkins for New York and about 250,000 checkins for San Francisco.

Now go check out the Mingle iPhone app, which displays this kind of data in real-time.

I just happened to be checking our AdSense account for the first time in a while, and noticed that one of the projects – stereotype – was now generating £2.50 a week and gradually increasing each week. It’s not enough to retire (£120 a year… that’s about $200 USD), but it’s better than a kick in the teeth.

The interesting thing about the project is that it’s a wonderful example of self-scaling SEO. I’ve done absolutely zilch in terms of marketing the site or hunting for backlinks, yet the site now attracts 600 pageviews a day, from almost entirely organic search traffic.

The growth of stereoty.pe pageviews since launch, over five months

When I created the site, I invested some time in structuring the page titles to appeal to users browsing Search Engine Results Pages (SERPs), and ensured that the structure of the site always closely linked multiple sections together, so as to create an easily crawlable “mesh” that distributes PageRank evenly across pages.

Most importantly, the site has slowly grown of its own accord. The database was originally populated with a list of 130 countries and 15 topics (women, men, beer, weather). An automated system then searches Twitter for combinations of these phrases (Swedish women, Swedish men, Swedish beer) every day, measures the sentiment, and stores the results.

Pages are only created for combinations that have enough relevant (high sentiment) data. As the data has grown over the last five months, so new quality, non-duplicate pages have slowly been automatically added and cross-linked into the site structure.

I don’t know how many pages have currently been “made live”, but eventually there will be 130 (countries) * 15 (topics) + 130 (country top-level pages) + 15 (topic top-level pages) + 1 (home page) = 2,096 pages. Yes, it could be construed as content-farm like, and yes it faces risk from an ongoing Panda-like update from Google that wiped out my other 2-day project, Fan Ranked. But for the time being I believe it provides some content value that isn’t provided by other websites and is a good example of how to get decent marketing results with little effort.

A couple of days ago Seth Godin wrote about The future of the library. While it is positioned as a love-letter to librarians and the latent potential in a new vision for the library, I see it as a dangerous and (ironically) outdated article.

Throughout our last year of travel, we relied on libraries – from Cardiff to Vancouver to Melbourne. Initially it wasn’t a positive decision to use them, more-so a “I suppose, if we really have to…” decision. But we quickly developed a deep appreciation and respect for libraries and the surprisingly modern services that they provide. So much so, that I now feel it is our personal duty to protect them.

Wherever we went, we could use a library. FOR FREE. We didn’t live there, but we were always welcomed and given warm shelter, free WiFi and a large desk with a convenient power outlet. It seems that many other people were also making use of the service – if you haven’t been to a library for a while and presume that most others haven’t either, you may be surprised.

Libraries are wonderful places to work, and many already meet Godin’s “future vision” of rows of available computer terminals and masses of convenient working areas. Some also have meeting rooms and other facilities that make them even more friendly to the development and exchange of information and ideas.

And yes, they still have books too. I’m currently sitting next to a pile of beautiful library-borrowed books – including wonderfully typeset and illustrated Tufte masterpieces – that are far superior to online equivalents. There’s probably about $250 worth of books in that little pile, and if there’s something specific we need, we can just order it. Isn’t that amazing, when you think about it? We can get any book we want, for free.

Libraries also offer an amazing array of other services, including DVD / Blu-Ray rentals and video game rentals. Mostly for free. As Godin states, I’m sure some librarians resent this “dumbing down” of their establishments, but isn’t this also the most incredible way to get people into the building, together as a community, and slowly inch them towards other activities? Getting people through the door is half the battle, so these services make sense to me. Plus, let me just re-state, they are mostly FREE. You can borrow a $60 video game for FREE.

I’ve also seen libraries with video game consoles inside the library, playgroups, and other non-literature-based services. These have been well used – it was incredible in Melbourne to see kids queuing for the library in the morning so that they could play games that they couldn’t afford to otherwise. And afterwards, they’d often progress to the comics or magazine section that had been strategically placed beside the consoles. Sure, it isn’t Mark Twain, but doesn’t the video game > comic > graphical novel > book progression just make sense to you? It certainly does to me. Well done, libraries.

My main gripe with Godin’s post, however, is that he seems to be almost blaming libraries for a lack of vision. No, Seth, what they’re lacking is CASH. And pointing out that they’re currently crap does not help their fight against cuts. They’re not rolling in money, but instead are facing reduced budgets every year. And you know what you can do with less? Less.

I’d like to return to the start of this post and ask Seth to do something that I’m trying: talk less, do more. It’s fine to point out foibles and wax lyrical about beautiful technical visions. But what libraries really need is support. They ARE heading in the right direction, but what we need to do is encourage people to get libraries back into the zeitgeist and to use them. When people realise how wonderful libraries are we will hopefully see more people willing to demand budget increases rather than cuts, which will help to further evolve their services. But moaning and navel-gazing won’t get us there.

If you haven’t visited a library for a while, I urge you to take 20 minutes out of your weekend and give one a try.

The title says it all, really.

I’m currently running two almost-identical scripts that pull data from the Twitter API every half an hour. The first version of the script runs at :00 and :30 minutes past every hour, and the second version at :05 and :35 minutes past every hour.

The on-the-hour/half-hour script fails (i.e. the API doesn’t respond) about two to three times more often than the 5 minute delayed version. Failed API calls can be identified in the sample screenshot above by 0 values – none of the calls should return a zero value.

So that’s it, really. The most likely reason is that :00 and :30 are peak times for API requests, so you’re more likely to make a request at these times to an overloaded API service. Shift your calls around a bit in the hour, and you’ll get a more robust response. This probably holds true for other APIs too.

We took on a lot of consultancy work last year, especially from August onwards. We got to work with some lovely people and on some excellent projects, but working seven days a week just didn’t leave any time to build our own things. We decided that we would really cut-back on consultancy work after December, and so far we’ve been fairly good at not taking on too much work this year.

At the end of December, I created a couple of 2-day projects (Stereotype, Fan Ranked) to try to get back into the swing of iterative, agile development. Actually, Fan Ranked was relatively successful, given the small investment: it was making about $20 per week in affiliate fees. Unfortunately, it was a little too late. A few weeks after launch, the Google ‘content farm’ update obliterated it from the search rankings (as it should, I suppose), and it now just sits there, gathering about five meagre visits a day. Still, these projects got my development-fu back in motion.

Over the next month, I started to build up a bigger app: Rosella Twitter Games. I made good progress, but soon decided that I should probably finish other commitments before embarking on larger projects. With that in mind, the last month I’ve had my head down with writing Designing Web App Success. I’m about 18 chapters into the 25, and making good progress. I’m REALLY excited about the book – it’s crammed full of good stuff, from business models to personas, typography to testing, development to SEO. I really want it to be The Definitive Manual for web apps. I’m a little fed-up with those books that are 20 chapters of the same thing, full of fluff and inspiration, but no real actionable information. This book is going to be the opposite: about 20 books condensed down into a single ‘need to know’ compendium.

We’re also about to ‘pivot’ the Contentini agency model / website, but I don’t want to say too much about that quite yet. We’ve built some apps under the Contentini brand over the last couple of weeks (e.g. Web Strategy Twitter Trends), so that might give you an idea.

Until next time, whenever it might be.