Introducing the Tiller Builder Rewards Program

Introducing the Tiller Builder Rewards Program

In April, we kicked off our 2022 Microsoft Excel Builders Challenge. Over the past 5+ months, the program yielded impressive results.

Community builders shared five new templates and workflows to expand the solution space available to all of us for our Excel personal finance riddles.

With these solutions comes new knowledge, prior art, and best practices we can each refer to and learn from as we refine our own tools.

And, @jpfieber’s enthusiasm for— and success in!— building templates concurrently on the Sheets and Excel platforms offers an inspiring model to future builders.

Builders, Start Your Engines!

We are excited to expand this program from a time-limited Excel “challenge” to an ongoing Builder Rewards Program that offers rolling awards to builders on both the Excel and Sheets platforms.

As with the Excel Builders Challenge, the Builder Rewards Program aims to inspire the creation of new spreadsheet-based solutions that empower people with greater understanding, confidence, and control of their financial lives. We hope to showcase the creativity and skills of Excel spreadsheet enthusiasts across the United States.

So, share your solutions on either— or both!— platforms and earn rewards from Tiller. Starting today, we will award prizes within 5 business days of your submissions.

Prize Levels

Prize level will be determined based on the quality, ambition, and value of your solution:

  • Tiller t-shirt
  • $25 gift card
  • 1-year Tiller subscription extension
  • $100 gift card
  • $500
  • $1,000

We encourage builders to publish templates concurrently to Sheets and Excel, as @jpfieber has made a habit of doing.

Prize awards will increase by 50% when templates are published on both platforms (e.g. what would have been a $500 template on a single platform, is awarded $750 when published on both platforms).

Curious about prize levels? Have a look at past submissions versus prize levels.

Judging Criteria

Prizes will be awarded by Tiller’s judging panel based on:

  • Value of concept to the personal-finance community
  • Value & quality of Tiller integration
  • Uniqueness of concept vision
  • User experience & usability

Solution Guidelines

Solutions should:

  • Empower people with greater understanding and control of their financial situation.
  • Solve specific personal finance riddles
  • Showcase what’s possible in a spreadsheet
  • Function reliably & performantly with clean design and formulas
  • Include helpful documentation— a video is a plus!

Requirements for Prize Consideration

  • Your solution must enhance the value Tiller’s transaction and/or balance data feeds
  • Your solution must be fully compatible with Tiller’s worksheet & column conventions, including dynamic column lookups in the Transactions, Categories and Balance History sheets (download the latest version of the Tiller Foundation template to see how these tables are implemented)
  • Solution must be posted as a new topic in either the Tiller Community’s Excel / Show & Tell category or Google / Show & Tell category
  • Your solution must identify and provide a workflow, solution or visualization to a common personal finance challenge. The topic must contain basic descriptive and instructional content for a user to understand the purpose of, be able to install and use your solution.
  • Your solution does not use scripts
  • Your solution does not integrate or use 3rd-party apps
  • You, the builder, are based in the U.S. and over the age of 18
  • Though you, the builder, will maintain ownership, copyright, and any other kinds of rights to the content, you grant Tiller an unlimited, non-exclusive license to use the resulting content, and/or portions of the content or derivatives of the content, in any way and for any purpose as Tiller solely determines

Originally published at: https://www.tillerhq.com/tiller-builder-rewards-program/

1 Like

Can you explain the motivation for “does not use scripts”?

P.S. As a software developer, I have noticed a common pattern of spreadsheet application development. They tend to start out simple, but as they grow, the ability to edit, understand, and test thee increasingly complex business logic requires (IMHO) that code stop being imbedded in the spreadsheet, but rather to be separated from (then called into) the spreadsheet. This has benefits for testing, version control, comprehensibility, interface definition, and collaborative work flows. Without this level of encapsulation to separate presentation from business logic, I find that it’s a slippy slope to becoming The Spreadsheet From Hell™ and becoming a Big Ball of Mud.

P.P.S. I am looking for a collaborator to create a work flow that joins both sides of a transfer. I’ve been thinking a lot about this, and that thinking is what has fueled my thinking above (and prevented me from committing to the effort).

1 Like

i’m a retired fintech guy, came here to ask the exact same question. i would add that scripting allows us
to develop a common api which interacts with a core library rather than have each developer reinvent the wheel each time. this speeds development and increases quality.

Great question, @michaelrwolfseattle & @quietdesperation.

We are huge advocates of taking advantage of all the tools the platform has to offer. That said, scripts present unique data-security security risks— especially when shared with users who aren’t able to assess them— and also are harder to maintain/keep current.

So, while we encourage you to build and share concepts leveraging scripts, we aren’t including those for award consideration in the context of the Builder Rewards Program.

Here’s my take on linked transfers:

Hear! Hear! I like that you mentioned API’s. Having been part of Open Source (since it was called Free Software), I was attracted to Tiller for an early mention of (what I remember as) open finance. That sounds like it’s ripe for a set of API’s.

A transfer should be atomic. One transaction, containing two transaction references to balancing transactions.

Currently a transfer is divisible (the antithesis of atomic). Two transactions. (Un)joined by zero cross-references.

I would like to (in SQL-ish lingo) – JOIN the two transactions in a way that models how they are in the real world - indivisible.

If this were a database, I’d create a join table something like this


CREATE TABLE transfer (
       ID int NOT NULL,

       fromInstitutionUUID varchar(32?),
       fromTransactionUUID varchar(32?),

       toInstitutionUUID varchar(32?),
       toTransactionUUID varchar(32?),

       PRIMARY KEY (ID)
 )

I could then

  1. create views that displayed all unjoined transactions then (in phased releases)
    v1 - allowed humans to reconnect transaction(s) into a single transfer
    v2 - provided hints for matching sides of a transfer
    v3 - automated the matching (and allowed for human intervention)

  2. create work flow and business rules that

  • enforced the atomicitity of the transactions
  • (stated difffereently) disallowed editing that would separate the sides or create inconsisgtencies
  1. Create reusable code (see beginning of this thread) that would give “views” or API’s to keep internal consistency and external ease-of-use (and re-use).

Thanks for the reply. I expected that this was not black/white, and that trade-offs were made.

Regarding security…

  • With respect to “users who aren’t able to assess them”… how is embedded code different from decoupled code?

  • The industry know how to manage code that’s written as text - open source communities evolved to git (having passed through CVS, Perforce, Subversion). Source Code Management a well-known practice that’s evolved over decades. As for non-text items (i.e. images, spreadsheets, MS Office docs (Excel, Word, Powerpoint)), that is (to my knowledge) an unsolved problem because there is not a good (to my knowledge) way to fork and merge “blobs”. (Well… fork is EASY. It’s the merg (from hell) that creates the problem for collaborative or community-driven development.

So… in my experience spreadsheets are harder to maintain/keep current.

A fundamental tenet of Open Source is that the source is (well, both “open” and also visible “source” code). That provides trust through transparency (instead of security by obscurity).

P.S. Thanks for the open discussion. I do understand that building a community, and a community-built solution is a DIFFICULT endevour, so I want to make sure you understand that I truly do appreciate that you are even attempting it. It WAYYYYYYYY beats beating my head against non-INTUIT-ive.com!!!

With the Tiller Community Solutions add-on, you can see that we have a viable approach to version control and pushing updates for spreadsheet templates. Though there are many options for public code repositories, pushing version-control scripts into spreadsheets is more challenging because a) the Sheets API doesn’t offer calls to manage/update bound scripts, b) the security risk is higher with scripts than spreadsheet functions, and c) our product footprint doesn’t currently include tools and controls to ensure the security of script published by third parties.

Again, please don’t take away from this conversation that we are discouraging users from using scripts to build the workflows of their dreams. Please! By all means! Go for it! We are simply saying that workflows dependent on scripts are not eligible for the awards of our Builder Rewards Program (at this time).

Thanks. I’m not as motivated by a reward as I am by reUSE. It’s much too complicated to justify a ROI with a user base of one. I’d only attempt it if I could share it, otherwise its “cheaper” to do manual work instead of (semi-)automating it.

Even if the solution is not eligible for a reward, is there a place to post solutions (to solicit collaborators - users and developers)?

… Is there a place to post solutions (to solicit collaborators - users and developers)?

That is the intent of the Google Sheets / Show & Tell category… but perhaps I’m misunderstanding…

Thanks. I’ve been so consumed with learning the product that I haven’t invested much time learning the community. Thanks!