The point was that with the VFP Executable -- like Xojo being discussed, this client's cost is: $0.0 per year.
1 Like
I was more concerned with including more realistic info about FileMaker pricing. I can make the store page show me similar numbers also, but it's important for people to also know that isn't the only way to price FileMaker deployment.
There is a segment of the dev world where the development cost is close to what the licensing cost may be. However, that's not always the case. There are also other "costs" that come with other platforms. It may be better, or not, depending on what you are doing, but this also isn't a binary topic. It's important for people to understand that nuance.
1 Like
With Visual FoxPro, you paid $500 for the development kit. That's it. It's totally free from there. Build a multi-user EXE, deploy it. Use it. No per seat cost. No "metering", etc.. There's still a vibrant VFP community and lots of customers.
Since I do mostly Java and Python, I'm not likely to take on Xojo also, but I like it's distribution model - like Java. Like Python. Like .NET. Like Full-stack in general. Like Visual FoxPro.
I still like FileMaker a lot for prototyping and for small personal apps.
I'm not against any of those. Just pointing out that "free" sometimes has a cost. Several FileMaker developers that I know personally, have moved to Xojo or an Open Source development environment. Of those, a little more than half have come back to FileMaker. And half of the others still do a lot of FileMaker work. After 4-5 years working in Xojo, my one friend said that his development time is 3-4x longer than it was with FileMaker.
Often it depends on what you are building, your business model, and what you value. The extra development time may 100% be worth it. And at the same time, it may not. Again, not a binary conversation based completely on the "deployment" cost. That's only one piece of the puzzle.
I look at the office I work at. They value quick turnaround and stable use so much more than anything else. They could never tolerate another environment. And the 2 FileMaker developers we have cost orders of magnitude more than our license cost. It's really very silly what we pay. Our development time is so much shorter in FileMaker. And the longer we use FileMaker the lower the cost of ownership is.
There is also a side of the conversation where it's important for the longevity of the company providing the tool to have recurring revenue. Those companies that didn't find a way to get recurring revenue have either gone away, or seriously reduced their growth/development resources.
1 Like
Are you talking about Xojo ? If so the development to support Android is going on. Xojo published a video showing what was accomplished. Looking very good, but it's not yet finished. Web API 2.0 will be released before Android. Web API 2.0 will be very good.
1 Like
As I recall, you've talked about XoJo for quite a long time. If you can, post some screenshots of stuff you've done. I'm sure everyone would enjoy that if the apps aren't too customer-private.
1 Like
Thanks for posting about ARGen, looks really good. I will look a that !
1 Like
If you compare Xojo to FileMaker, you swap time against license cost.
As you start to build in Xojo all the things you love in FileMaker.
So with Xojo you may need 100+ hours to get your framework done and have database, printing and window handling right, before you cost your business logic.
Thinks you get in FileMaker included, but you pay more license fees.
3 Likes
Just to put it into perspective. License cost for us, cost about $3-5/hour if you annualize it. Even at it's highest cost, if you break the annual costs down, it's really low. If you spend 25 hours a week working on a custom app for a year, for a group of 5 people, the license cost is $0.70/hour.
That's the developer's cost. But the customer also has a cost for his licenses plus the cost you charge for development. True with Xojo you may take more time, but the raise in the price goes in the developer's pocket. That's the way reasoning some do.
FMS is interesting in that you don't need to set loads of parameters, it's almost plug-n-play. But you hit a bug in FMS, that can be a pain. FMS introduced a new console, wonderful, but removed many things you now need to change via the command line.
Nothing's perfect, but to some FMI/Claris ways of doing are inconvenient. Have you ever see FMI/Claris president doing demonstrations or leading Web discussions ? Xojo's president does this. At the beginning of 2020 it did some presentations and answered questions. Mine was "when will the debugger get some more functionalities like variable watches ?". The answer was that he understand my frustration - this guy knows development - and added it's in the plans, but feels that this would bring less bangs for the bucks than other things they are working on. Wow, I like when the president knows what he his talking about !
2 Likes
So, that kind of reads like "take longer so I can make more money". It's one of the core problems with billing by the hour. But that's for a different discussion.
As has been discussed elsewhere, is there really any cost that isn't incurred by your clients?
Another question, for a given project what is the cost for the additional time for the company? If you are building a custom app that either helps increase revenue, or decreases cost, there is a cost due to the time to deployment. That, at times, can be a significant factor in the decision to go with one technology vs another. Even things like redesigning the visual layer of a website has a reason, and time becomes a key factor for many businesses.
The thing we are pricing is value, and when you remove the need to force a specific technology, and choose the one best suited for the project/task/goal, it is a better scenario for the client and the developer.
1 Like
Ha I watched that and thought 'thats a good question"!
Look I understand the argument re return on investment. My issue is, as a single developer, I do not have the customer base to draw on that are willing to pay FileMaker prices. My solutions are bespoke pieces of work, some database, some hardware interfacing (scanners, printers, handheld devices etc), some data manipulation (ETL, reporting etc). These are typically solutions for a couple of users - an example:
The customer has an ERP system. They have a timber mill who cut, edge pieces of timber for customers. The timber mill use a totally paper based scheduling process - the ERP doesn't handle this so the rest of the business have no visibility of the schedule. My proposed solution was to use FileMaker with an ODBC link into the ERP to extract job information and present this via Webdirect to around 6 people. My proposal with FM licensing, hardware (server and licences) and my development time was around £7k. Plus a recurring annual cost of £1400 just for FileMaker.
The client literally laughed at my proposal and said they would rather use Excel - which they are doing.
Now if I was to develop that in Xojo or another such platform my proposal would have been in the order of £3k for my time, the web app could have run on their existing server hardware, and the annual cost to the client is ZERO in licences but I would charge them a maintenance fee of say 15% for my support of the solution.
Now it may be that FileMaker was the wrong tool in this case. Unfortunately it always looks like it's the wrong tool at this end of the market. The removal of the runtime is a huge mistake in my opinion but that has been discussed many a time and probably not best to get into that here.
2 Likes
Whether you are doing FileMaker development, or Xojo, or anything else...I highly recommend listening to Jonathan Stark's Ditching Hourly and The Business of Authority podcasts.
I don't want to sound like I'm saying use FileMaker at the cost of all else, because that's not what I do, nor how I think. Picking the right tool for the job is a crucial part of any project. However, I don't want to see you just substitute one proprietary tool for another as a solution just to keep doing the same thing, and as Jonathan talks about, get involved in the race to zero.
1 Like
Correct I was talking about xojo and I had watched the video from 2019 on there development status. It looks like they are making good progress. I am curious who will support Android first FileMaker or xojo.
With Android having over 50% share in the us and over 80% world wide I was a little surprised that a none Apple owned company like xojo would support iOS and not Android. I just googled the market shares so not sure exactly how accurate it is but from my understanding Android has been the market leader for many years now.
Any type of solution is appealing for sure. programing instead of scripting also appeals to me. and as I have mentioned in other posts if they supported Android now I would be testing it out. I could see this being something I grow to love for my personal projects. In time that might lead to work hard to tell.
2 posts were split to a new topic: What’s in the “bill”
+1. A few years ago I became sufficiently frustrated with Go and the SDK and took a break to learn Swift (iOS). After the FileMaker Data API came out, I took that ability to build iOS apps and started experimenting with connecting the backend to FileMaker. Which led to me writing SwiftFM (GitHub - starsite/SwiftFM: SwiftFM is a Swift framework for the FileMaker Data API). Now I build native iOS apps with sync, offline use, etc., all using FileMaker record data. Which is a good segue to Josh's point. 
Exactly. If a client's happy with their FileMaker backend and just wants an iOS app for their team, I'll build them a standard iOS app with SwiftFM. Hundreds of users, without the expensive hundreds of users FileMaker license. If they don't have a backend, I can opt to build something quick in FileMaker, or I’ll use CloudKit (free) if they need to scale beyond hundreds. The backend is almost unimportant, it's the same URLSession call in Swift either way.
These are both great points. At the end of the day, your client is paying for a result. Not how many hours it takes you, or the cost of whatever stack you're using. And the more you specialize, the more you can charge. Sounds like you're on the right track on both. 
I narrow things down by discarding Android entirely. If I had decided to learn Kotlin instead, I'd be making Android apps, or maybe I'd have learned React Native and started building hybrid apps. But, developing in Swift makes me happy, so that's where I've landed.
...
I looked at stuff like Xojo and LiveCode (after having learned Swift), and did some back of the napkin math for creating and hosting mobile apps with the UI and feature set I wanted. For me, there was no benefit. If I wasn't already proficient in Swift, that would surely be different.
All of Xojo's premium features are baked into Xcode and Swift, so I don't pay for features or plugins, I just import whatever framework I need and write it myself. I pay $99/year for an Apple Developer Subscription, but that's pretty much it. Anything beyond that is revenue. 
Good luck on your new path with Xojo! As some have noted, it is a smaller community without the installed base or resources of an Apple (Swift), Microsoft (Kotlin), or Facebook (React), but they appear to be dedicated to improving the platform. Go build something great with it! 
3 Likes
I’ve got some experience with react native and tried to learn some swift. Well I learned swift as a language so i’m quite comfortable with it. Native ios and droid dev is quite similar. I would say that android studio handles ui stuff better. Process is really similar. Or it was. I have not used swiftUI’s production ready version but at least beta was massive improvement for a web developer like me. It is so similar to react, angular and vue in its approach to create ui views (declarative) so it felt like an easy to learn path (have had no need to create apps so have not explored it any further yet).
2 Likes
For me learning a tool like Xojo would need probably years of work. I have fm in my toolbox and it’s great for some things. I do mostly web development and by that I could do probably 95% of the client requirements that most of my clients or potential clients have. If using FM is possible for client and its project, I push for it because it’s probably 10x less work and even with license and server costs it’s cheaper. Also new features are much easier to develop later. Makes it easier to sell.
Probably the next RAD tool should have javascript as scripting language to make it popular. Like google tried with its app maker.
for me too that is the only reason to at least give XOJO a try. One project with several hundred unknown users who get their runtime for free to promote my customers platform.
The old version was based on open Word docs, the competitions tries Word, Excel, PDF forms. The runtime was great but it's gone. For me that leaves two options: give away the project or try to port to another platform. I'll go with number 2.
That said the backend of the system will stay on FM with 40+ VLA and a deep workflow integration in the FM solution. What a waste of time for me or better waste of $$$ for the customer.