Recent blog posts…
Commercial property prices have struggled in many areas over the last few years, and as a result we've seen a few business plans submitted to us with buying a building to house the company as part of the plan. For newcos seeking investment this is usually a show-stopper with professional investors, and is likely to be challenged on a number of grounds.
- First of all, it changes the need for funding. Say one needs a first round of $1m and then $500k to buy a building. If one doesn't buy the building it materially changes the investment needs.
- Secondly, it changes the cashflow model. Investors may want to drip-feed money based on various objectives. They can't do that with a large capital item like a building. If the company survives its first few years then perhaps making a real estate investment to save money over a decade or so might make sense. But hopefully there will be better opportunities in the business to create value.
- Thirdly, it mixes the activity of the business. Tech startups should be applying capital to being tech startups, not property speculation companies. Typically, investors going into a newco at best 1-in-10 chance of getting a big return on their money, even at series A. It is unlikely to fit the investment committee criteria in a big fund: if the fund's capital is designated for early stage, they would want a $1m investment to go into startups, and not half and half into property. Investments like this are rarely capital efficient. Buying a building isn't going to give a "hockey-curve" return in the way that the rest of the business might. In fact, if the business is growing rapidly there are many circumstances under which one might consider selling any company building and investing the money in growing the business instead, for a better return.
- To this end, buying a building looks like a hedge: that the entrepreneur may be worried it won't work and wants a source of rental income to fall back on if it goes wrong. If it goes wrong, however, things won't work that way with the investors.
- Finally, it's worth considering how this might affect an exit from the business. If one has built up $1m of saleable business value and wants to sell out, that extra $500k which was raised and spent on property will increase the transaction price by 50% and not give any extra upside on disposal. It's just a barrier to the entrepreneur getting paid out.
Ultimately, if one has been offered a sweetheart deal on property, it's worth raising any capital separately and in a different vehicle. Tying it up with a newco deal will make investors nervous that it's some sort of mechanism for extracting the funds straight out of the company they're investing in. This is very much like entrepreneurs paying themselves large salaries -- it's only fine when it's their own money!
We're always happy to share thoughts on this at the usual address.
Earlier this week we launched our latest product, the DMG Extractor. This is handy little tool designed to make it easier for Windows users to extract files from DMG / Disk Image archives, commonly found on OS X. In particular, this is useful for users emulating OS X in a Windows environment, or building and distributing software for Apple products. We will appreciate any comments on the product!
Some time ago we wrote a popular blog article explaining how to extract call detail recording log files from a Nortel Business Communications Manager telephone system.
Since then we have had a number of enquiries from people asking whether it is possible to fetch the log files without having to set up an FTP server. Well, I'm pleased to say that today we are launching (for free!) our new CdrPuller utility. This uses the CDR Pull technology built into all Nortel and Avaya BCM systems to allow you to pull log files from the telephone system and save them into a local folder of your choice.
We have updated our original blog article to reflect the new utility, but if you want to cut to the chase you can download the new tool.
And if you're interested in processing call detail logs to produce reports for management (or just to be able to easily search for particular numbers) do check our our BCM Call Logger utility.
We've just launched version 3 of our award-winning iPhone Backup Extractor software. For those of you not familiar with iphonebe (as we call it), the software provides a way to recover information from the iPhone or iPad backup files that are automatically created when you sync your device with iTunes.
"But what use is that?", I hear you ask. Well if you lose or damage your phone then the only official way to recover the lost information is to sync your new phone. But in order to do this you've first got to buy a new phone and then hope that the restore process works properly (which is by no means guaranteed). And what if you've already got information on the new phone that you wish to keep (the Apple restore process wipes out anything already on the device)?
In those cases your only hope is to recover critical data from an existing iPhone backup file. And that's where the iPhone Backup Extractor comes in. Since we launched the software in early 2009 we've helped thousands of people to recover data ranging from priceless family photos to business-critical contact data.
And with our latest update we've now added location extraction. If you've been following the recent newspaper reports then you'll know that it's been discovered that iPhone devices keep a record of where they've been. With iPhone Backup Extractor 3 you can retrieve this information as a KML file which can then be imported into Google Earth. Why not give it a go - you may be surprised just how accurate it can be!
As always you can download the iPhone Backup Extractor for FREE from http://www.iphonebackupextractor.com.
The SYDI project is an Open Source project aimed at helping network administrators document their network. It uses a series of VBScript file to collect system data which is captured in XML and then transcoded into a variety of other formats. The project's homepage has a lot more information.
We've been working with SYDI to capture data for our IT management tool, awdit (currently in beta), and in the process have come across and resolved a few issues in the stock SYDI scripts. In the interests of keeping it open, we've patched our changes back into a fork of SYDI on GitHub, and are freely releasing our native client for personal and internal business use.
Updated SYDI server collector script
Users can download the updated SYDI server collector script here. We've taken version 2.3 and patched in better support for date handling alongside an upload function to send data to awdit.
However, we've come up with an option that works much better for us...
SYDI-compatible awdit collector scripts for x86 and x64
The awdit collector for Windows tool collects data and can save or upload it in SYDI XML format, much like the original SYDI script. However, our native binary versions have the following benefits over the original VBScript:
- Much faster, multithreaded collection of data
- Native, secure, digitally signed .exe format which is smaller and easier to run, with an optional x64 binary for even faster operation on newer machines
- Dates from installed software are better normalised to easily readable formats (although there is still a lot of variation to be found in the registry)
- Where dates aren't present in the registry, we provide an approximate date from the installed file, and prefix the date value with a tilde (~) to indicate the value is approximate
- XML output is nicely formatted
- A number of quirks on virtualised systems have been ironed out
- Application architecture is reported in a new
architecture attribute in regapplication or msiapplication tags
- Install locale and language settings are reported in a new
language attribute
- Product keys are more reliably collected
- Simplified arguments which are also displayed when double-clicking the file in Explorer
- New TSR (terminate and stay resident) mode where the collector can be left running and can automatically generate new XML every few days as configured
- No nasty spyware, malware, calling home, etc.
None of the changes made have broken compatibility with the original scripts or XSLT, so the new client can be used in environments previously running the VBScript version. At it's simplest, you could use the awdit collector to dump XML on your machine like so:
awdit-collector-win-x86.exe --file=my-machine.xml
Downloads
Please do send us your feedback on this script -- we'd love to hear it!
Running the collector over a network
There are a number of approaches for running the awdit or SYDI collector scripts over a network. Using the TSR mode can work well on servers, or advanced users can use group policy to schedule periodic launches of the tool. We'll be sharing some best practises that we've learnt. In the meantime, we detail what is possibly the simplest approach below.
Group Policy Editor can be used on a domain to force all domain clients to run the relevant script file as part of their logon process.
- Open Group Policy Editor on your domain controller and load up your default domain policy (or create a new domain policy if that is more appropriate)
- Expand User Configuration | Windows Settings | Scripts (logon/logoff) and double-click the Logon option in the right-hand pane.
- Click the ‘Add’ button and either browse to or paste in the path to the
run-sydi-network.vbs file in the Script Name box.
