LaSalle Software News #21: Converting With Clients

Wednesday May 16th, 2018

Episode Summary

Welcome to my twenty-first LaSalle Software News podcast.

This is Bob Bloom from Toronto Canada. 

Today is Wednesday, May 16th, 2018. 

I publish LaSalle Software News monthly, at the top of the month except for September, to update you on my LaSalle Software. 


When the first release of Version Two of my LaSalle Software is done, I plan on joining the Richmond Hill Board of Trade.

Well, I am a bit away from that first release, but I decided to join now anyways.

A couple of years ago I went to a RHBOT breakfast networking event at the Richmond Hill main library. The food was really good although I was not that hungry. It was well attended. They went around the room and everyone introduced themselves with their “Elevator Pitch”. I concluded at the time that it would be a good idea to join the RHBOT at some point because here was a ready-made way to network with potential local clients. I’ve been getting their emails ever since

I keep putting off joining, mainly because my Software is not ready. But I concluded that “now is the time” to join. It’s not like I’m going to tag the initial release of my Software, and then the next day find clients at a RHBOT event. Networking takes time. And funny enough, it would be great to connect with local businesses who can sponsor York Region PHP meet-ups. But I think that, instinctually, I need to get out more. I need to hang out with devs. And, I need to connect with the local business community. Joining the RHBOT is a natural, ready-made way to connect.

There was a time when I actively avoided pursuing local clients. So joining the RHBOT with the intention of on-boarding local clients is a complete change for me. Basically, a complete180.

When I talked to the nice people at the RHBOT when I filled out the forms, I realized pretty fast that whenever I talk about clients, my hostility towards clients is very clear. Yes, I harbour hostility, and channelling that in the general direction of potential clients not productive. So, I decided then and there that my upcoming podcast will be about clients.

I’ve been touching on the topic of clients in my podcasts here-and-there, but never really getting into it. For this podcast, my intention is to clearly hit it head-on. So, I knew that I would want to write out my podcast completely in advance, which would take me a couple of weeks since I would edit my podcast endlessly. Meaning that my software development would be taking yet another pause. If I actually formatted my transcription properly, and perhaps word things in the right way, I could refer potential clients to it so that they would understand my stance.

Getting my podcast out at or near the first of the month is a hugely important to me. I’ve tried different things to keep to this deadline, and have succeeded this year. However, this podcast is different and a delayed publication is warranted.

I Develop Custom Web Applications

What is a web application? Web apps are viewable in browsers, that do just about anything that you need done. Actually, you can program web applications to do things that never display in a browser, such as overnight notification runs.

Websites? People understand websites. Web applications? People do not understand web applications. I have decided that in describing what I do, that I will prefix “web app” with the word “custom”. People understand “custom”. They assume what I do is expensive! I am finding that people understand “software”. So if I substitute “software” for “web applications”, saying “custom software”, then there’s more understanding. The phrase “Custom Web Software” seems like an inherently understandable idea.

I am a web applications developer, specializing in the superb Laravel Framework.

I am working on free open source software (FOSS) with which to base client engagements. This software will have the basic web app features my clients — and myself — need. It will be based on the Laravel Framework. I call my software “LaSalle Software”

LaSalle Software Version One exists and works. I wrote all the basic — and some not so basic — functions for a ready made blogging application. Features included automatic database form creation, SEO features, two factor authentication, and an administrative back-end, among other features . It is a monolithic architecture, written as a suite of installable packages, and was a great starting platform for further custom web application development.

The first version of LaSalle Software needs work. It needs to be updated to the current version of the Laravel Framework. The code needs to be cleaned up. There are new features to include. So I set out to do all this stuff, release it as Version Two, and then go seek clients. Well, something happened during this update.

The entire concept of Version Two changed. I decided to drop the approach of putting all the features into one single web application. Instead, I would separate things into — wait for it — their own separate web applications. In general, I stopped using the “Monolithic Architecture”, and adopt the “Micro Services Architecture”.

There are two main reasons why I want to use micro services: because I can; and, because the payoff is bigger.

The cost of the technical infrastructure to support micro services architecture has come down drastically. So much so that small business owner-managers can adopt micro services architecture as the springboard to grow their web based software as a profitable line of business.

The payoff is bigger because we can do more things that make more money with micro services than with monolithic. I know this is debated, rather fiercely, but IMO micro services architecture is very much here to stay because it yields fundamental business benefits that monolithic web app architecture cannot match.

Not having done micro services before, it’s been a huge rabbit hole of learning. I basically have to start Version Two from scratch. So Version Two is on a new road, and as a result is taking much longer than anticipated.

Family of Long Term Clients

I am about to talk about clients in a way I have not expressed before. I know that for some people, this is going to come across as, well, perhaps as offensive. Or merely as a big turn off. Or perhaps I’ll be perceived as having “an attitude” or “just another consultant who thinks highly of himself”.

Well, whatever will be, will be. It’s been quite a journey, with many clients, with many IT contract jobs, and many situations under my belt.

I decided that the only way to really talk about clients is to talk from my heart. To convey what I am really thinking.

I am now seeking a nice little family of long term clients. Maybe half a dozen to a dozen, representing a varied aggregate portfolio of web apps, which generate a varied aggregate portfolio of revenue.

I am not looking to build an agency with a ton of clients and a ton of teams.

I am not looking to start renting office space.

I am not looking to hire full time staff.

I am looking to support my web app projects with small teams of talented freelancers. Likely people I know, or people referred by people I know, from the local technology groups that I help organize.

Now, this is critical: I want to invoice each client every month. More precisely, I want to invoice each web application each month.

This is the elemental, fundamental, feature of the web applications in my consulting portfolio: these web apps either make money every month; or, produce significant savings that free up money. Money with which to pay me! Essentially, the web apps in my consulting portfolio generate the money that pays my monthly invoices.

This is the absolute core idea of my consulting: that the custom web applications in my consulting portfolio pay my monthly invoices.

In my experience, it is rare that a website or web app makes money, or manifests sufficient value, each month. Rare!

So, if your custom web application is generating money, then you are doing something that is not common.

The difficulty in building money-making — or money-saving — custom web applications and websites is one reason why many consultants are in the business of doing builds only. Clients typically have cash for the build. The only invoice-able money is that initial cash. Since the thing that is being built will very likely not generate revenue, the consultant has no expectation that there are further invoice-able opportunities beyond the build.

These consultants are in the business of finding new short-term clients. They don’t build e-businesses, they close deals. The client is buying a finite, fully pre-defined product.

Typically, the client is not concerned with the technical infrastructure and tools. The client is typically concerned with the delivered end product.

There is certainly money in doing only builds. And some builds do spawn post-delivery invoice-able opportunities. But the real business is client acquisition, and the game is keeping as much of the finite build money as possible. The client is going away, it’s a one-and-done deal. It’s build-and-run. It’s churn-and-burn. Yesterday’s deal is ancient history. Today’s deal is yesterday. It’s all about getting tomorrow’s deal.

What I want is completely different. I want uninterrupted monthly invoicing. The invoice-able amounts are not finite. My focus is building my clients’ e-assets. My client list is finite.

My clients and I are engaged in custom software development. Requirements are rarely fully pre-defined before coding begins. Which is a profoundly different activity than delivering a fully formed product. My clients are not buying software. My clients are creating software!

Need An Exquisite Understanding of Value You Offer and Value People Are Looking For

Building a revenue generating web app requires an exquisite understanding of value. What is the Value Proposition? What value do people seek?

It is enormously difficult understanding value.

Once you understand value, then two equally enormous tasks await: what is it exactly that you want people to do; and, how do you get people to do what you want them to do on your site.

Your Value Proposition, your Call(s) To Action, and your Conversion action.

When you look at your custom web application this way, the end result will be a front-end that will be completely different than what you thought it was going to be. In fact, it may end up being completely counter-intuitive.

I look at things things backwards:
What do you want people to do on your website (Conversion) ?
How are you going to get them to do what you want (Calls to Action) ?
What is the value that you are offering (Value Proposition) ?

Then, I frame just about everything in terms of abandonment — which I know can be incredibly irritating. Abandonment is just that: people leaving your site — and probably never returning. Unfortunately, abandonment is the single biggest action people take, so this abandonment is my usual default starting point.

We Are Doing Custom Software Development — You Are *NOT* Buying Ready-Made Software

It is important to understand that we are doing custom software development.

This means that you are not buying software!

I am not installing pre-fabricated, ready-made, software for you. We are building software that does not yet exist together!

You know what I learned about developing custom software? It is intimate!

It means that we have to work as a team.
It means that we have to collaborate.
It means that we have to use some type of software development project methodology.

We Produce The Project Culture: Pathologies and Politics Sublimate Into The App, Producing Abandonment

Boy, is that a mouthful.

In my experience, the dominant culture within a tech project becomes the dominant theme embedded in the thing that is produced. So much so that I find the joke, a camel is a horse designed by a committee, not funny anymore.

People are people. Office politics is office politics. And before you know it, what is ultimately produced is an abandonment machine.

It is enormously difficult to attain an exquisite understanding of value when “people are people” and when “office politics is office politics”, the probability of achieving “an exquisite understanding of value” drops exponentially.

In my experience, client pathologies sublimate into what we are creating, destroying conversions. Since conversions — getting people to do what we need them to do — is the transactional moment a web app generates money, it is important to leave client pathologies at the door.

I know you are the client, I know that you are paying my invoices. But I also know that we have to put our talents and perspectives together — to collaborate — to create a conversion machine, not an abandonment machine. I cannot begin to count the number of clients I’ve had who do all sorts of things to demonstrate that they are the powerful clients and because they are paying me I need to just do what they tell me.

People are people and people want to be in control. But we’re building custom web-based software that is supposed to make money every month, month after month after month.

I Advocate Iterative Development of a Disposable App

I am a huge proponent of the Disposable App during requirements gathering. It is incredibly cheap, and the payoff is huge.

You know the concept of what you want, but unsure about what exactly to create? How do get from concept to web application?

My answer: create a little web application. Play around. Whip up a quick database. Punch in some fake data. Create a few forms. Keep it basic, get a feel for things. We’re eventually going to delete this web app, so no need to get fancy.

How much does it cost to whip up a disposable web application? While the barista is making our coffees, I can whip up a new Laravel based app on my MacBook Pro. Although we really should get this web app on a cloud server, which I can do for myself on my own accounts in 15 minutes.

Then it’s like figuring out a recipe. Do this do that. No, that’s not what I want. Back up, try something else. There’s no risk because you are not going to break anything in your systems. You can feel things out. Call people over to take a look. Change a bit of this and a bit of that.

Iterative development. Make a change, get feedback. Rinse and repeat. No need to know everything first. Just discover what is needed as we go along. Build a little prototype. Get feedback. Update your prototype.

In my experience, iterative development with a disposable web app produces the best answers. Better than a “requirements document” and endless emails back-and-forth and lengthy threads in Basecamp. And do you know why this is so? Because the focus is on an actual product, and that product is an actual web app.

You can feel a real, even if ultimately disposable, web application. You can touch it. You can see the underlying code. You can see real forms. You can send out real emails. You can try out real overnight processes and see the results the next morning. It’s tangible.

Disposable apps with iterative development — excellent combination!

Case Study One: Bricks and Mortar With Web App

Combining bricks-and-mortar with web applications — in this case, it was a website — is very powerful. In this case study, based on a real client, the store was akin to a specialty food shop in Niagara-on-the-Lake. The store was located on a main tourist-y street, the owner held store events parallel to street and town events, participated in street and town events, and also had an commence store.

So there were three main themes: events, brick-and-mortar store, and commerce.

The three themes translated into these value propositions, which flowed into these calls-to-action: um… errrr…. well… the value propositions and calls-to-action were not well defined. Not anywhere near anything like being “exquisitely understood”. Although, over time, the owner absorbed an incremental awareness.

So the website did something that is very common: it laid out a buffet for visitors. The home page visitor had to wade through a whole lot of everything in order to find out how they wanted to proceed through the site. The peripheral areas of the home page — the header, footer and, unfortunately, columns, had densely packed general information about the store, along with a few links into internal web pages. The body of the home page included upcoming events, and scrollable calendar for events, pictures of the store, products, and testimonials. The footer included a newsletter sign-up form and a link to the local tourism bureau. I am sure I forgot something — oh yes, recipes! The footer included a couple of recipes using products sold at the store.

The layout was “responsive”, meaning that the entire page collapsed into one long scrollable thing. Especially on a phone, there was a whole lot of scrolling going on for the visitor to find what they are looking for — if they have the patience.

There was a time, back in the day, when you could put anything and everything on your home page. People would take the initiative to click through websites. Those days are very much over.

No one wants to sign up for newsletters, so the newsletter form is never submitted.

No one bothers looking at recipes.

Ecommerce sales are rare.

There is no call to action with the events, but people are asked informally where they learned of the event and due to the “top of fold” placement upcoming events, some people do attend from the website.

Ecommerce sales are mostly from tourists who agree to be receive emails so they can buy items on sale from their home town.

The owner had the ambition of the website commerce being a huge sales machine. The idea was that the brick-and-mortar presence would give people the confidence to buy online to site visitors from the Continental U.S.

The reality was the opposite: the website drives brick-and-mortar store traffic. Those who consummate in-store purchases and agree to receiving emails became, essentially, “members” of the e-store.

Tourists research destination stores before leaving their hotels. So the home page should convince people to make the store a destination.

The e-store should be off the home page completely, and should be a membership only store with e-marketing geared to on-boarding members, seasonal specials, and favourite item replenishment delivered to one’s home.

Case Study Two: Compelling Feature Product

An e-store with a compelling feature product, sold as a hobby, where the product is ancillary to a bricks-and-mortar store. The e-store had a lot of products, tools, parts, and supplies, but basically sold one product only and one set of supplies.

This e-store had a lot of potential. A micro services architecture would have really come in handy because multiple front-ends using completely different domains coupled with a single back-end would have been terrific.

What was entirely unique is that a lot of people who came to this site were ready to buy, and they would be interested in learning about new models of the featured product.

The site spent almost all its real estate on convincing people to buy. It was not easy for people to figure out how to actually buy.

The home page was hopelessly cluttered, filled with products no one bought and with information no one cared about.

People wanted to see the featured product, they wanted to know the shipping rate and delivery areas, sometimes they wanted supplies, and they wanted to know what connection the owner of the site had with the product.

Incredibly, people researched the product elsewhere. The decision to buy was a separate research exercise that resulted in links to my client’s website.

But the website was never streamlined to cater to buyers. Nor what it streamlined to sell essentially the one product people were looking for. The cart needed substantial work to lower abandonment.

You Are Going To Need A Bunch of Accounts

Your going to need a number of accounts associated with your web applications.

When it comes to domain registration, clients must own their own registrar accounts, and ensure that their names and addresses are associated with their domains. There is no other way to unequivocally demonstrate domain ownership. My general advice is to never, ever, delegate domain registration.

You need many different accounts to do web applications.

You need a software repository account.
You need the Laravel Forge account for web app set-up on the cloud server.
You need a cloud account. If this is not Amazon, then you will also need an Amazon Web Services account.
You potentially need a Continuous Deployment account.
You potentially need an app monitoring account.

Clients often want to avoid the hassle of maintaining their own accounts. It’s a convenience thing. Why be bothered when your consultant can “take care of it”.

The problem is account ownership. Who really owns your accounts — me or you?

Probably a worse problem is control: do you control your accounts or do I control your accounts?

In my experience, it is better for both of us that you clearly own and clearly control your own accounts.

You will never be locked out of your accounts.

You will always see what is going on with your accounts.

You will be billed directly for your accounts so you know exactly what you are paying for your account.

If you do not like what I am doing, you can change my passwords.

You will need a software repository account. This is a must. If you are ok to have your software viewable (and downloadable) by the entire world, then these accounts are free. Otherwise, private “repos” accounts will cost. You will have an account at or Although is a popular choice (free private code repositories, free up to 5 users), I found that it is best when using the Atlassian tools (e.g., JIRA). The pricing has changed for GitHub and GitLab, see:

GitHub pricing

GitLab pricing

You will need a cloud server account. I use Digital Ocean.

You will need a Laravel Forge account to set up cloud servers for Laravel Framework based web apps.

You will need an Amazon Web Services account.

You may need other accounts.

SEO versus Conversion

Strictly speaking, I do not “do” SEO.

I’m not the person who is going to get your site listed number one on Google.

However, I do believe search engines love original content, and that at a minimum you need to add original information-rich content onto your site at least once or twice a month.

I believe that you need to put content on your own site, and not on another site.

I also believe that it is a lot easier engaging in SEO activities than in focusing on conversion. What do all those people who find you do when they get to your site? What are they supposed to do when they get to your site? What is important to you?

Remember: I think backwards! So the first thing I think about is not SEO, but conversion — the action that we want people to take! And when I think of conversion, I think of it in its opposite: abandonment. Because, the way I see it, if it is not conversion, then it’s abandonment!

I am intensely interested in conversion. Very intensely interested in conversion.

I also believe that SEO becomes more effective when you do it backwards.

To Laravel Framework Or Not To Laravel Framework

A shout-out to one of our wonderful York Region PHP regulars who sent me the link to this Quora discussion Why do some people still use pure PHP if there are so many incredible PHP frameworks like Laravel?”.

This is a turn of phrase along the classic line that it is not a good thing to be married to a framework. This question is sure to come up as I talk to people about web applications, so let’s talk about it now. Great timing to receive this link when I did — thank you!

Even better timing is the latest interview at "Voices of the Elephpant", who just interviewed the Composer authors.

Things have changed. So the premise of the question is out-dated. It is not a binary decision whether to use PHP frameworks. As they pointed out in the interview, the PHP frameworks are not “monolithic” anymore.

More than ever, we can use the best tools for the job. The reason is due to Composer. So the frameworks are breaking themselves up into pieces, and making these individual pieces Composer installable.

For me, I specialize in Laravel so I want to use it. That’s my bias. I always have the option of not using it, or using only those pieces that are relevant, if that’s what the job warrants.

We have an abundance of choice now, more than ever. It’s very exciting!

A Word About WordPress

It seems to me that if a potential client has a website already, then that website is probably done with WordPress.

What is WordPress? It is the world’s most popular blogging software.

WordPress comes with a lot of standard features, including a full adminstrative back-end. It is easy to install, it installs on shared hosts and cloud servers, it is updated regularly with security enhancements and feature improvements. For the features that do not come with WordPress, there is a breathtaking universe of third party layouts and features that are installable into WordPress. So it’s not a big deal to get an ecommerce website going with Wordpress.

WordPress is free. A lot of the third party stuff is free. Yes, free. Anyone can download WordPress. There is an entire eco-system of nominally priced themes and plugins.

Yes, I know WordPress. Yes, I support WordPress sites. In fact, I’ve been using WordPress for at least a decade. It just so happens that it is not my tool of choice. I much prefer to be in actual web application development.

I think if you want to know my opinion about WordPress, we need to go out and have a beer. With phones turned off.

If you do not have a lot of money to build a website, and you really want a website, then you can buy your hosting for a couple of dollars per month, you can buy your domain for $10, and then you can install WordPress onto your host for free. Perhaps buy and configure a prepared theme (caveat: not always as straight forward as it looks), install some plugins, and voila! You have a website.

If I were to focus on site builds only, then I would probably focus on WordPress. WordPress is not only free, but it is open source, meaning that I can see the actual behind-the-scenes software. Even better, I can mess with the source code anyway I want, for free! Yes, really! Ask me when we have that drink, and I will take you on a tour. So if I focused on site builds, I would mess with WordPress to make it even easier to install, configure and customize. Why? Because my number cost when doing a build with WordPress is labour. The less labour, the more of that build invoice I keep for myself.

I really do not want to be in the WordPress business. Nor do I want to be in the “build” business.

I am not 100% sure what I will do when the time comes to work with WordPress, to be honest. I think I’ll just take it on a case-by-case basis. There are articles about using an established WordPress website with the Laravel Framework, so I may be digging into these articles one day.

I am definitely not going to be your deep discount low cost web guy. The nature of the custom web applications I do precludes that.

Not only that, but things have changed. At one time, back in the day, quality web hosting that could reliably run WordPress cost a fortune. It was manna from heaven that WordPress, and a bunch of other similar projects, were offering a free open source blogging platform to install on this expensive hosting. The cost of buying blogging software was nuts. So WordPress and other new projects allowed people to have websites. But that was then, and today is today. The economics of the cloud has changed, to the point where it is within reach for an small business owner-manager to run a micro services architecture portfolio of web applications. For all intents and purposes, the marginal cost of installing WordPress these days is effectively zero — really, just the cost of my time.

As much as I have struggled to create free open source software to provide the basis for deploying micro services architectured web applications, I am where I need to be, and where my small business owner-managers need to be. Why? This is where the overall business value resides. The fact that there are no established off-the-shelf free open source software such as what I creating is validation enough that I am doing precisely what I should be doing. Not that there is not any software out there. But things are still evolving. The technology and infrastructure is still evolving.

WordPress to do a website? Ok! WordPress as a technology platform to grow your digital lines of businesses? No.

Local PHP Groups Update

The end of the 2017-’18 meet-up season is upon us.

I am the organizer of York Region PHP and York Region Laravel.

I am the co-organizer of Laravel Toronto.

And I am now the co-organizer of GTA-PHP.

Being active in these meet-up groups gets me out talking to other local PHP devs. It’s great! Great to talk tech, and great to network.

I am putting the York Region Laravel group on hiatus. I am keeping the Twitter account, the meetup dot com group, and the domain, so I can kick-start it back up when the time comes. It’s too much bootstrapping a second York Region meet-up group. The Laravel Framework certainly gets enough attention in the York Region PHP group anyways!

York Region PHP has enjoyed a terrific season.

Just our second season, our core group is growing. Holding all the meet-ups at the Magna Centre turned out to be very beneficial. After the first season, the stability of having meet-ups in one venue has been soothing. The venue itself has been a success. Although it is not a “corporate” environment, and the audio-visual support is limited, I think we’ve come to take some things for granted. Such as: plenty of washrooms and ease of getting to them; tons of free parking; easy to get to; doors are always open and there’s staff at the front; there is a Second Cup kiosk; there is always a lot of people which makes it feel nicer than entering an empty building after hours.

The room rental is not free. I arranged and sponsored all the room rentals this season. Which, I sense, contributed to a feeling that we all pitched in this year to follow-through on a successful first season.

It was liberating to not hold meet-ups at corporate venues, to be honest. We all showed up which was not easy given that everyone has a busy schedule. But the growing core group wants this group and it shows!

Our growing core group delivered the presentations, which was fitting for this season.

We held the meet-ups northward, which turned out to be the right thing to do. There is a growing population of PHP devs above Elgin Mills Road who will not venture to meet-ups in south York Region, and absolutely refuse to head downtown to the Toronto meet-ups. We now have a core group from central York Region, as well as have people visiting from the north-west and north-east areas of York Region.

Another outstanding feature of the York Region PHP group this season is the construction! The new subway opened. VIVA construction is, shall I say, pervasive, on Yonge Street at Hillcrest Mall and west on Highway 7. The Davis Drive Rapidway opened. Construction on Bayview northward from Elgin Mills is incredible. The Gormley GO Station opened recently.

I have concluded that York Region PHP, and the PHP devs in York Region in general, want to see downtown styled presentations right here in York Region. So I will have this in mind when I start planning the 2018-’19 season in a few weeks.

Being a co-organizer of the GTA-PHP and Laravel Toronto meet-up groups should help in making this happen!

My Recent Micro Services Architecture Presentation

I presented “Micro services in a Laravel Environment” at last week’s York Region PHP meet-up.

Here’s the link.

It is really about my journey with the micro services architecture for version two of my LaSalle Software. A journey filled with angst! And angst is what came across in my presentation.

The ongoing discussion was a help. And the post meet-up advice I received was a big help. Thank you!

I sense that there was enough info about micro services, OAuth2, and JSON Web Tokens (JWT), to serve at least as an introduction.

I have pretty well decided that I’m going to implement a very scaled down version of OAuth2, because I control both the front and back ends, because I want to use software that I understand completely, because I want very understandable software, and because there is a lot of OAuth2 authentication flows that I just do not need.

I have also pretty well decided that I’m going with a scaled down version of JWT. I agree with the notion that the JWT header be excluded when you control both the front and back ends so the encryption method is not defined with the token. As well, I am wondering if I really need a signature, because the signature encrypts the payload. Why not just encrypt the payload when you control both “sides”.

Thank you for the general advice about security. Very helpful.

When I get this podcast done, and tweak my website, I’ll be at it with my Software.


You have been listening to a production. Opinions expressed are not necessarily those of SouthLaSalleMEDIA dot com, nor of the organizations represented. Links and materials discussed on air are available in the Show Notes for this show. Information contained herein have been obtained from sources believed to be reliable, but are not guaranteed. Podcasts are released under a creative commons licence. Some rights are reserved. Email correspondence to the attention of Bob Bloom at info at SouthLaSalleMedia dot com.

Monthly report on the good, the bad, and the ugly of my ongoing LaSalle Software development. Produced by Bob Bloom, founder and developer of LaSalle Software.

      All Episodes