41–50 of 59 posts
for those who can't use excel...
https://drive.google.com/file/d/0Bxgh-9Z9zd40ZExtRnYyZVhWU2s...
Feature development on the app will be faster (and reach a broader audience) than the spreadsheet, however. And I wanted to learn AngularJS ;)
Struggling with maintaining 25 versions of financial projection spreadsheets for a tiered SKU based SaaS startup. I decided to spin this up as quickly as possible (and learn a little AngularJS along the way). The result - after ~30 hours it's usable enough to show. Obviously needs more flexibility around the variety of revenue models and expense categories. But really it's just for rough estimates at this point.
I like it. Nice work and welcome to the land of Angular! Minor spelling issue I noticed that was bugging me all over the place: s/Reccuring/Recurring/
Struggling with maintaining 25 versions of financial projection spreadsheets for a tiered SKU based SaaS startup. I decided to spin this up as quickly as possible (and learn a little AngularJS along the way). The result - after ~30 hours it's usable enough to show. Obviously needs more flexibility around the variety of revenue models and expense categories. But really it's just for rough estimates at this point.
This is absolutely fantastic. I would pay real money for something similar tailored to product sales model (vs recurring SaaS).
You can download here: http://www.startupmodels.com/download/
I haven't used it myself but I know that it has helped quite a few companies work through their financial projections around here. It's at least a decent starting point.
(More info: http://www.siliconprairienews.com/2011/10/startup-models-see... )
Earlier quoted context omitted.
As a piece of technology, this is really cool. But I guess I don't get how it's different from a nice Excel model. How is it that this allows you to capture 25 different use cases in a way that the a spreadsheet can't?
A few things I was thinking: - Spreadsheets are prone to fat-fingering and messing up formulas. For example, if you built a spreadsheet with three product SKU's and wanted to add a fourth, it's not so easy. Especially if you have visualizations tied to specific ranges of cells, etc. With this app I can validate data once and not worry about some random missing formula screwing it up down the road. - When creating mod…
Earlier quoted context omitted.
As a piece of technology, this is really cool. But I guess I don't get how it's different from a nice Excel model. How is it that this allows you to capture 25 different use cases in a way that the a spreadsheet can't?
A few things I was thinking: - Spreadsheets are prone to fat-fingering and messing up formulas. For example, if you built a spreadsheet with three product SKU's and wanted to add a fourth, it's not so easy. Especially if you have visualizations tied to specific ranges of cells, etc. With this app I can validate data once and not worry about some random missing formula screwing it up down the road. - When creating mod…
Perhaps it's because I've spent many, many hours using Excel (although less so these days), but those problems you state don't seem like problems:
1) Fat-fingering is a problem only if you mix the task of coding (setting up the structure and formulae in Excel) with the task of using (changing the parameters). You don't code your web site at the same time as using it (except for manual testing), and it can be the same with Excel. Highlight all input cells with a yellow background and blue font, unset their 'Protected' property, and then lock the workbook. You/anyone can then play to your heart's content without worrying about messing up formulae.
2) When you are creating new versions of a spreadsheet, it's either because you are changing the structure (e.g. changing formulae, adding columns) or because you are changing the input data. If the latter then, yes, you can have several different versions. I've managed this in the past (when fundraising and doing regular reviews with investors) by having an 'Assumptions' tab which contains _all_ inputs. Each scenario (set of assumptions) has a name/number and a column of its own. The calculations and output dynamically reference just one scenario at a time depending on the scenario chosen from a drop-down. Not only that, but Excel's 'Data tables' feature (which explicitly supports only one-variable or two-variable scenarios) works with this, even if you have 10s of variables: just set the scenario number as your variable.
3) Using a 'template they found' is clearly a bad idea. They wouldn't just copy-paste some 'code they found' without studying it and the tests. In fact, for something simple, they'd probably just re-create their own after studying someone else's code for something similar. It's the same with Excel files.
4) Can't argue with this one :)
5) This last point intrigues me: until now I thought you were focused on business plans, and that you wouldn't overwrite the historical data with actuals. However, you mention operational data, suggesting you are talking about combining planning and tracking into one tool. Is this correct?
Earlier quoted context omitted.
Sure, but the OP could have just published their spreadsheet and you wouldn't have to build that either.
This was the worksheet I created (and have been using for a few months). I believe funded.io is at feature parity with this simplified model - https://drive.google.com/file/d/0Bxgh-9Z9zd40ZExtRnYyZVhWU2s...
A few suggestions which may save effort next time you do this:
- Only use the $ symbol as much as necessary. Usually you only need one (e.g. $C12 or C$12 rather than $C$12), unless you're referencing a single input. In your example, the excessive use of $ on the 'Detail' tab prevents me from adding an extra row for an employee simply by copying-and-pasting
- SUBTOTAL can be better than SUM for summing columns of numbers. You want subtotals for Sales, Support etc., as well as a grand total. SUBTOTAL can be applied to a whole column of values without fear of double-counting, as it ignore existing SUBTOTALs.
- EOMONTH(x,1) will give you the last day of the month after the date x. EOMONTH(x,0)+1 will give you the first day of the month instead. It's a bit easier to read than your DATE(YEAR, MONTH+1, DAY) construction.