1DayLater is evolving…

For the past year or so we have been working on building a new 1DayLater from the ground and I’m letting myself get excited about it; this blog post is clearly premature, but what the hey, I want to write a little about what we’re doing.


your 1DayLater is evolving…

Technology Wise

The easiest changes to describe are our technologies, almost every choice made in the original system has been reviewed and (mostly) found wanting. We’ve really matured the software with this new version and myself as a programmer too; I’m growing ever more comfortable with the iterative development process to the point that I consider a bad day as NOT pushing a new release live.

A lot of this has come from building the NexGen software with Lucion Environmental (more on this another time) suffice to say that when you support a diverse and growing company you see the fruits of your labour almost instantly. If the person in the room next door has a bug and they see it fixed instantly there’s gratitude aplenty!

I digress, here’s some of the changes we’ve made on the new 1DayLater… and why

  • Version Control: Subversion > Git
    once you get over the initial learning curve, git has many advantages
  • Deployment: FTP > Git Hooks
    we can update the site with simply “git push” and all the right files will be in place
  • Hosting: Rackspace > Amazon Web Services
    an excellent developer community and lower price makes this logical
  • Database: MyISAM > InnoDB
    currently 1DayLater is non-relational, we now require a more logical relational structure
  • Markup: Handcoded > Twitter Bootstrap
    frankly, I can’t afford to spend too much time pushing pixels - this makes it much quicker to knock up pages
  • Templating: Custom > Handlebars
    I wrote my own templating engine and it was very patchy, we picked the most popular and active engine for the new system
  • PDF Printing: wkhtmltopdf > PrinceXML
    once we go live we will (gulp) fork out the licence fee for a commercial printing program; after all this will be our new product
Product Wise
But if you prefer I can quickly explain what we’re making:
  • Our Users can create Quotes to send to their clients
  • Quotes are made up of Line-Items with an estimate tally
  • Users can then Log their Activity against these Line-Items
  • They can then convert their Activity into Invoices to send to their clients
For example
  • Tony the plasterer Quotes for a small Job
  • It is made up of these Line-Items
    • 3 Days on site at £250 / day
    • 1 Disposable tarpaulin at £30 (estimated)
    • 1 Day of Van hire at £60
  • On site he logs his work against these activities, on the second day he notices his client has torn the tarpaulin so he gets another one and so logs two of that
  • He can then draw up an Invoice
The idea is that Tony does the MINIMUM amount of admin but gets access to some very valuable information and tools, ie:
  • Send Invoices and Quotes to his clients
  • Get notified when his clients view his Invoices and Quotes
  • Find the Quotes with outstanding work (ie money)
  • See which Invoices are overdue
  • Visualise his profitability
Furthermore he can inviate collaborators to log their activities against his Quotes (maybe he hires staff etc.)

Business Wise
Well, we’ve paid off the business loan, we’re financially stable (profitable in fact) and are busy investing in the company. On the financial front we’re pretty happy at the moment but (as all businesses should) we want to be very profitable and hire more staff for support and whatnot.
With the new product we spent a great deal of time pondering how to price the product and catch customers at each stage of the curve, this is what we thought:
  • When is the product valuable?
    • When the client sends an Invoice
    • we thought that the data, visuals, outstanding work etc were valuable, but that they’re also so intangible that would be difficult to describe and sell
  • How much is an Invoice worth?
    • ONE POUND
    • We decided that it couldn’t impact on the value of the invoice but had to be a nice round number, a QUID seems decent. We’ll review this soon enough
  • How can our users pay for it?
    • On a subscription (Monthly or Yearly)
    • Buy a set number of Invoices (Tokens)
Last time round the finances were second to the product, this time we’ve actually gone ahead and designed and implemented our payment pages first. Yup, before the product is even finished; we don’t want bugfixes and whatnot getting in the way of our cashflow, after all if 1DayLater wasn’t financially viable (for us) those bugfixes and improvements would be worthless as the service would eventually disappear.
Lessons have been learned. I am excited.

1 Notes/ Hide

  1. oodavid posted this

Recent comments

Blog comments powered by Disqus